SlideShare a Scribd company logo

OCCI Monitoring at OGF42 - Concepts and demo

Augusto Ciuffoletti, profile picture
Augusto Ciuffoletti

The document discusses the OCCI (Open Cloud Computing Interface) monitoring extension developed by Augusto Ciuffoletti, focusing on its framework, core concepts, and applications for monitoring cloud resources. It emphasizes the importance of monitoring resource performance to meet service level agreements and user expectations, proposing a simple ontology for resource monitoring. The monitoring framework involves extracting, aggregating, and delivering performance metrics, introducing new resource and link types, including 'sensor' and 'collector.'

Software
Related topics:
Cloud Computing Insights • Distributed Computing
1 of 176
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
OCCI monitoring extension Augusto Ciuffoletti OCCI monitoring extension and its proof of concept Augusto Ciuffoletti Dept. of Computer Science - Univ. of Pisa September 5, 2014
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default) New! This feature is not included in the available revision of the document
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure The resources we want to monitor: they have a Collector Endpoint mixin associated
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Create one Sensor resource
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Use two collectors to define the measurement activiy
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Associate two metric mixins to the Collector X
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure And another two metric mixins to the Collector Y
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Associate two aggregator mixins to the Sensor
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure One publisher is going to use raw data from the collector
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Another is going to receive measurements from the aggregators
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure A frame for Collector X and its mixins
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure ... one for Collector Y...
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure ... one for the sensor
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure The scope of the Sensor (for hook labels)
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding the aggregators: a,b,d are hook labels
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding publisher 2: aggregated (f,g) and raw data (e)
OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding publisher 1: measurement stream b is multicast
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure End of part 1
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti From the OCCI to Java: unfolding the infrastructure A Java backend for OCCI monitoring Augusto Ciuffoletti Dept. of Computer Science - Univ. of Pisa September 5, 2014
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An example: monitoring load and connectivity of a Compute resource I The measurement of the average CPU load is sent outside the cloud as a UDP flow I The connectivity with the gateway is collected in a log file on the sensor.
From the OCCI to Java: 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 to Java: 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 to Java: 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 to Java: 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 from the collectors
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The sensor launches a Collector Manager thread for each collector in the scope
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The Collector Manager invokes (by RMI) the measurement threads on the source I Each of them opens a TCP connection with the sensor socket
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The Collector Manager creates the pipes used for communication I There is one pipe for each hook label in the scope I Records from the socket are multiplexed to pipes according with hook identifiers
From the OCCI to Java: 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 to Java: 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 to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I One publisher is going to use raw data from the collector
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The monitored resource runs a daemon with an RMI interface (MetricContainer) I The sensor has a TCP server-side port accepting connections I The sensor learns the RMI interface from OCCI documents
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The CollectorManager on the sensor calls a remote LaunchMetric method on the metric container I The parameters include I the name of the metric mixin I the attributes of the mixin, encoded as a JSON object
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The MetricContainer creates a metric thread (using reflection) I The metric thread opens a connection to the Collector socket on the Sensor
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I All metrics associated with a Collector share the same TCP connection to the Sensor
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The messages from the metric to the Sensor are JSON documents, tagged with the destination hook
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Finally, the experiment I A virtual network with guest + 3VM I One VM acts as “coordinator”, in fact simply holding the OCCI specs as application/occi+json documents in a 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 to Java: unfolding the infrastructure Augusto Ciuffoletti On the sensor Launched by an external manager that allocates sensors to dedicated hosts
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti On the monitored compute resource Launched as a consequence of the presence of a MetricContainer mixin
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti On the web server I the CollectorEndpoint starts first I the Sensor downloads the documents that describe its scope (caching!)
From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Conclusions of the experiment I The proof of concept still needs some work to be finished (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 blueprint for a real implementation
From the OCCI to Java: 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” (into hook, or channel)
From the OCCI to Java: 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” (into hook, or channel)

More Related Content

ODP
Prototype Implementation of a Demand Driven Network Monitoring Architecture
Augusto Ciuffoletti
 
PDF
Open Cloud Computing Interface
Augusto Ciuffoletti
 
PPTX
ネットを信じていいですか？
sirousagi1989
 
ODP
IEEE1588 - Collision avoidance for Delay_Req messages in broadcast media
Augusto Ciuffoletti
 
PDF
Automated deployment of a microservice based monitoring architecture
Augusto Ciuffoletti
 
PDF
Extending the OCCI API with monitoring capabilities
Augusto Ciuffoletti
 
PDF
Monitoring a virtual network infrastructure - An IaaS perspective
Augusto Ciuffoletti
 
PPT
Segmenting Major Donors Versus Planned Givers
Jim Friend
 
Prototype Implementation of a Demand Driven Network Monitoring Architecture
Augusto Ciuffoletti
 
Open Cloud Computing Interface
Augusto Ciuffoletti
 
ネットを信じていいですか？
sirousagi1989
 
IEEE1588 - Collision avoidance for Delay_Req messages in broadcast media
Augusto Ciuffoletti
 
Automated deployment of a microservice based monitoring architecture
Augusto Ciuffoletti
 
Extending the OCCI API with monitoring capabilities
Augusto Ciuffoletti
 
Monitoring a virtual network infrastructure - An IaaS perspective
Augusto Ciuffoletti
 
Segmenting Major Donors Versus Planned Givers
Jim Friend
 

Viewers also liked (10)

PDF
Design of a secure "Token Passing" protocol
Augusto Ciuffoletti
 
PDF
TIP: a course about IP convergence technology
Augusto Ciuffoletti
 
PDF
Network Monitoring in the age of the Cloud
Augusto Ciuffoletti
 
PPTX
Catholic School Enrollment Strategies That Work
Jim Friend
 
PPTX
2012 ICSC Annual Appeal presentation
Jim Friend
 
PPT
Advancement Office:101
Jim Friend
 
PPTX
2014 Diocese of Allentown: A Success Story
Jim Friend
 
PPT
St. Barnabas Parish, Bayville, NJ
Jim Friend
 
PPTX
Icsc pres electronic media 2010
Jim Friend
 
PPT
AIG - The Fallen Giant
My own sweet home!
 
Design of a secure "Token Passing" protocol
Augusto Ciuffoletti
 
TIP: a course about IP convergence technology
Augusto Ciuffoletti
 
Network Monitoring in the age of the Cloud
Augusto Ciuffoletti
 
Catholic School Enrollment Strategies That Work
Jim Friend
 
2012 ICSC Annual Appeal presentation
Jim Friend
 
Advancement Office:101
Jim Friend
 
2014 Diocese of Allentown: A Success Story
Jim Friend
 
St. Barnabas Parish, Bayville, NJ
Jim Friend
 
Icsc pres electronic media 2010
Jim Friend
 
AIG - The Fallen Giant
My own sweet home!
 
Ad

Similar to OCCI Monitoring at OGF42 - Concepts and demo (20)

PDF
ZHAW 2016 - OCCI for monitoring
Augusto Ciuffoletti
 
PDF
Charlton Barreto - The OGF | Open Cloud Computing Interface
CloudCamp Hamburg
 
PDF
2013 03 occi-monitoring
Augusto Ciuffoletti
 
PDF
OCCIware
OCCIware
 
PDF
Open Cloud Computing Interface
Jean Parpaillon
 
PDF
OCCIware@POSS 2016 - an extensible, standard XaaS cloud consumer platform
Marc Dutoo
 
PDF
OCCIware: Extensible and Standard-based XaaS Platform To Manage Everything in...
OW2
 
PDF
OCCIware, an extensible, standard-based XaaS consumer platform to manage ever...
OCCIware
 
PDF
Charlton Barreto - The OGF | Open Cloud Computing Interface
Symposia Media
 
PDF
OCCIware @ Paris Open Source Summit 2017 - a standard, extensible Cloud consu...
Marc Dutoo
 
PDF
Presentation of OCCIware, a standard, extensible Cloud consumer platform at P...
OCCIware
 
PDF
#OSSPARIS17 - Développeurs, urbanisez la consommation de vos Clouds et APIs a...
Paris Open Source Summit
 
PPTX
IGT2009 The Open Cloud Computing Interface
Shlomo Swidler
 
PDF
OCCIware project and OCCI standard presented at China Cloud Computing & Stand...
OW2
 
PDF
OCCIware project and OCCI standard presented at China Cloud Computing Confere...
OCCIware
 
PDF
OGF Cloud Standards: Current status and ongoing interoperability efforts wi...
Florian Feldhaus
 
PDF
OCCI XML representation
Jean Parpaillon
 
PDF
Cloud standards interoperability: status update on OCCI and CDMI implementations
Florian Feldhaus
 
PDF
Model and pilot all cloud layers with OCCIware - Eclipse Day Lyon 2017
Marc Dutoo
 
PDF
OCCIware presentation at EclipseDay in Lyon, November 2017, by Marc Dutoo, Smile
OCCIware
 
ZHAW 2016 - OCCI for monitoring
Augusto Ciuffoletti
 
Charlton Barreto - The OGF | Open Cloud Computing Interface
CloudCamp Hamburg
 
2013 03 occi-monitoring
Augusto Ciuffoletti
 
OCCIware
OCCIware
 
Open Cloud Computing Interface
Jean Parpaillon
 
OCCIware@POSS 2016 - an extensible, standard XaaS cloud consumer platform
Marc Dutoo
 
OCCIware: Extensible and Standard-based XaaS Platform To Manage Everything in...
OW2
 
OCCIware, an extensible, standard-based XaaS consumer platform to manage ever...
OCCIware
 
Charlton Barreto - The OGF | Open Cloud Computing Interface
Symposia Media
 
OCCIware @ Paris Open Source Summit 2017 - a standard, extensible Cloud consu...
Marc Dutoo
 
Presentation of OCCIware, a standard, extensible Cloud consumer platform at P...
OCCIware
 
#OSSPARIS17 - Développeurs, urbanisez la consommation de vos Clouds et APIs a...
Paris Open Source Summit
 
IGT2009 The Open Cloud Computing Interface
Shlomo Swidler
 
OCCIware project and OCCI standard presented at China Cloud Computing & Stand...
OW2
 
OCCIware project and OCCI standard presented at China Cloud Computing Confere...
OCCIware
 
OGF Cloud Standards: Current status and ongoing interoperability efforts wi...
Florian Feldhaus
 
OCCI XML representation
Jean Parpaillon
 
Cloud standards interoperability: status update on OCCI and CDMI implementations
Florian Feldhaus
 
Model and pilot all cloud layers with OCCIware - Eclipse Day Lyon 2017
Marc Dutoo
 
OCCIware presentation at EclipseDay in Lyon, November 2017, by Marc Dutoo, Smile
OCCIware
 
Ad

More from Augusto Ciuffoletti (11)

PDF
An open-source testbed for IoT systems
Augusto Ciuffoletti
 
PDF
0 basic
Augusto Ciuffoletti
 
PDF
Thingspeak: integrazione
Augusto Ciuffoletti
 
PDF
Thingspeak: fondamenti
Augusto Ciuffoletti
 
PDF
Design and implementation of a low-cost modular sensor
Augusto Ciuffoletti
 
PDF
Laboratorio Openstack
Augusto Ciuffoletti
 
PDF
Collision avoidance using a wandering token in the PTP protocol
Augusto Ciuffoletti
 
PDF
The wandering token
Augusto Ciuffoletti
 
ODP
Grid Infrastructure Architecture A Modular Approach from CoreGRID
Augusto Ciuffoletti
 
ODP
Scalable concurrency control in a dynamic membership
Augusto Ciuffoletti
 
ODP
Network Monitoring in the age of the Cloud
Augusto Ciuffoletti
 
An open-source testbed for IoT systems
Augusto Ciuffoletti
 
0 basic
Augusto Ciuffoletti
 
Thingspeak: integrazione
Augusto Ciuffoletti
 
Thingspeak: fondamenti
Augusto Ciuffoletti
 
Design and implementation of a low-cost modular sensor
Augusto Ciuffoletti
 
Laboratorio Openstack
Augusto Ciuffoletti
 
Collision avoidance using a wandering token in the PTP protocol
Augusto Ciuffoletti
 
The wandering token
Augusto Ciuffoletti
 
Grid Infrastructure Architecture A Modular Approach from CoreGRID
Augusto Ciuffoletti
 
Scalable concurrency control in a dynamic membership
Augusto Ciuffoletti
 
Network Monitoring in the age of the Cloud
Augusto Ciuffoletti
 

Recently uploaded (20)

PDF
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
ghrom2211g
 
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
PDF
iTop VPN Free 5.6.0.5262 Crack latest version 2025
itskinga12
 
PDF
Autodesk AutoCAD Crack Free Download 2025
hggfcrd hgggref
 
PPTX
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
IT IDOL Technologies
 
PDF
Cost to Outsource Software Development in 2025
Omega Incorporations- Best Software Development Company
 
PDF
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
deepakkhaitan3
 
PDF
Internet Downloader Manager (IDM) Crack 6.42 Build 41
ghrom2211g
 
PDF
Nekopoi APK 2025 free lastest update
umarali35kp
 
PPTX
Computer Software and OS of computer science of grade 11.pptx
GauravDahal9
 
PPTX
Oracle Fusion HCM Cloud Demo for Beginners
DharanOracleerp
 
PDF
Tally Prime Crack Download New Version 5.1 [2025] (License Key Free
itskinga12
 
PPTX
AMADEUS TRAVEL AGENT SOFTWARE | AMADEUS TICKETING SYSTEM
philipnathen82
 
PDF
How to Make Money in the Metaverse_ Top Strategies for Beginners.pdf
Herond Labs
 
PDF
Navsoft: AI-Powered Business Solutions & Custom Software Development
Navsoft
 
PDF
wealthsignaloriginal-com-DS-text-... (1).pdf
skmiani786
 
PDF
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
Andre Kraus
 
PPTX
Reimagine Home Health with the Power of Agentic AI​
AutomationEdge Technologies
 
PDF
Salesforce Agentforce AI Implementation.pdf
Robert Mark
 
Adobe Premiere Pro 2025 (v24.5.0.057) Crack free
ghrom2211g
 
Internet Downloader Manager (IDM) Crack 6.42 Build 42 Updates Latest 2025
itskinga12
 
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
iTop VPN Free 5.6.0.5262 Crack latest version 2025
itskinga12
 
Autodesk AutoCAD Crack Free Download 2025
hggfcrd hgggref
 
Agentic AI : A Practical Guide. Undersating, Implementing and Scaling Autono...
IT IDOL Technologies
 
Cost to Outsource Software Development in 2025
Omega Incorporations- Best Software Development Company
 
EN-Survey-Report-SAP-LeanIX-EA-Insights-2025.pdf
deepakkhaitan3
 
Internet Downloader Manager (IDM) Crack 6.42 Build 41
ghrom2211g
 
Nekopoi APK 2025 free lastest update
umarali35kp
 
Computer Software and OS of computer science of grade 11.pptx
GauravDahal9
 
Oracle Fusion HCM Cloud Demo for Beginners
DharanOracleerp
 
Tally Prime Crack Download New Version 5.1 [2025] (License Key Free
itskinga12
 
AMADEUS TRAVEL AGENT SOFTWARE | AMADEUS TICKETING SYSTEM
philipnathen82
 
How to Make Money in the Metaverse_ Top Strategies for Beginners.pdf
Herond Labs
 
Navsoft: AI-Powered Business Solutions & Custom Software Development
Navsoft
 
wealthsignaloriginal-com-DS-text-... (1).pdf
skmiani786
 
T3DD25 TYPO3 Content Blocks - Deep Dive by André Kraus
Andre Kraus
 
Reimagine Home Health with the Power of Agentic AI​
AutomationEdge Technologies
 
Salesforce Agentforce AI Implementation.pdf
Robert Mark
 

OCCI Monitoring at OGF42 - Concepts and demo

  • 1. OCCI monitoring extension Augusto Ciuffoletti OCCI monitoring extension and its proof of concept Augusto Ciuffoletti Dept. of Computer Science - Univ. of Pisa September 5, 2014
  • 2. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 3. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 4. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 5. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 6. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 7. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 8. OCCI monitoring extension Augusto Ciuffoletti The OCCI framework I There is an interface between the user of a cloud service and the cloud service itself I Data entities that describe the service traverse this interface during its provisioning I The protocol used during this conversation follows the REST paradigm: I the user plays the role of the client I the conversation follows the HTTP protocol I responses are cacheable, as far as possible I OCCI proposes a minimalistic conceptual framework (or ontology) for the entities used to describe the service
  • 9. OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
  • 10. OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
  • 11. OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
  • 12. OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
  • 13. OCCI monitoring extension Augusto Ciuffoletti The OCCI core concepts I Anything is an entity, and is identified with an URI I A relationship between entities is an entity I we distinguish resource entities and link entities (relationship) I There are many kinds of entities, with distinguishing attributes I An entity of a certain kind can be integrated with mixins that carry more attributes or bind existing ones
  • 14. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 15. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 16. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 17. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 18. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 19. OCCI monitoring extension Augusto Ciuffoletti OCCI IaaS interface I The first use case for OCCI, adopted as an open standard I Resources are processors, storage, networks. I Links are network interfaces, and processor/storage associations I Mixins add OpSys attributes to a processor, a filesystem to a storage, etc. I However OCCI is designed to smoothly adapt to diverse use cases I Here we want to propose its application to monitoring the performance of cloud resources
  • 20. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 21. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 22. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 23. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 24. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 25. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 26. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 27. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 28. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 29. OCCI monitoring extension Augusto Ciuffoletti Motivation I The monitoring of resource performance is a key issue to implement: I Service Level Agreement, a defined target to obtain user confidence I fault-tolerance targets defined by the user I The user wants to customize resource monitoring I the user may be in his turn a service provider I the user may simply want to verify the quality of the service I 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 monitoring that is aligned with OCCI
  • 30. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 31. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 32. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 33. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 34. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 35. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 36. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 37. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 38. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 39. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 40. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 41. OCCI monitoring extension Augusto Ciuffoletti A monitoring framework I Monitoring is made of three basic activities: I extract performance parameters from the target Resource I aggregate them and compute the metric of interest I deliver the measurement to the relevant party I The last two steps consist of aggregation and rendering of data I this makes a candidate for a new Resource kind I The first step entails the collaboration among entities I this makes a candidate for a new Link kind I The resource kind is named Sensor, and the link kind Collector I and this is bare minimum for a stand-alone monitoring framework I The OCCI monitoring framework complements any OCCI framework I it handles any type of Resource.
  • 42. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 43. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 44. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 45. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 46. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 47. OCCI monitoring extension Augusto Ciuffoletti A Sensor I It is a distiguished activity that needs the provision of cloud resources I Tightly integrated in cloud infrastructure I Under control of the provider I Tuned using user requests I The provider defines the available aggregation and publishing capabilities I The user instantiates the Sensor as a composition of such capabilities
  • 48. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 49. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 50. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 51. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 52. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 53. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 54. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 55. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 56. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 57. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 58. OCCI monitoring extension Augusto Ciuffoletti Describing a Sensor I Any Sensor has a few generic features I ...they can be included in a standard definition of a Sensor I When the sensor operates I How frequently the sensor produces a new measurement I They are timing attributes I Other features are specific for the provider I ...they are defined as mixins for the sensor I 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 mixins I however the hooks to connect a Sensor to a Collector must be defined
  • 59. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 60. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 61. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 62. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 63. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 64. OCCI monitoring extension Augusto Ciuffoletti A Collector I Represents a flow of measurements between a OCCI Resource 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 the configuration of the Collectors I Cross provider measurements can be implemented I ... to accomodate the utilization of several providers with a unique dashboard Sensor
  • 65. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 66. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 67. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 68. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 69. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 70. OCCI monitoring extension Augusto Ciuffoletti Describing a Collector I As in the case of the Sensor there are generic attributes of a collector: I The sampling period I The accuracy of the sampling period I ... again, just timing I Other attributes are defined by provider-specific mixins with an arbitrary semantic I ...the metric that is measured (throughput, free space, temperature etc.)
  • 71. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
  • 72. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
  • 73. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
  • 74. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
  • 75. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default)
  • 76. OCCI monitoring extension Augusto Ciuffoletti A monitoring-aware Resource I A Resource that is the target of a monitoring activity may be explicitely characterized with a Collector End-Point mixin I Such a mixin contains the description of the monitoring modality for that resource I for instance, the location of a log file I The presence of this mixin allows cross-provider interoperability I As an alternative, the modality can be left implicit (default) New! This feature is not included in the available revision of the document
  • 77. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 78. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 79. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 80. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 81. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 82. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 83. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 84. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 85. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 86. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 87. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 88. OCCI monitoring extension Augusto Ciuffoletti The overall picture I Two entity kinds I Sensor aggregates and delivers measurements I Collector acquires measurements I Four mixin types I Aggregator mixins describe the aggregation activity of a Sensor I Publisher mixins describe the rendering activity of a Sensor I Metric mixins describe the measurement activity of a Collector I Collector Endpoint mixins describe the monitoring access point of a target resource I The two Kinds have a OCCI schema associated I ...they are defined in the standard I The Mixins may be associated with a provider specific schema I ...but we do not exclude that some of them may be part of another standard
  • 89. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 90. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 91. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 92. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 93. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 94. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 95. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 96. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 97. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 98. OCCI monitoring extension Augusto Ciuffoletti Hold them together: input and output hooks I The designer needs a tool to assemble a monitoring infrastructure I we introduce input and output attributes for the Mixins I We introduce hook attributes (named attributes in the last revision) for a mixin: I their value corresponds to a label I Input attributes I Output attributes I Input and Output hooks with matching labels are connected I this may mean a data flow among them I The scope of hook labels is limited to a sensor and its adjacent collectors I The provider indicates hook semantics in the specifications of the mixin
  • 99. OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
  • 100. OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
  • 101. OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
  • 102. OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
  • 103. OCCI monitoring extension 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 of the two resources (total four tools) I We combine a metric from both resources (e.g., average load)
  • 104. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure The resources we want to monitor: they have a Collector Endpoint mixin associated
  • 105. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Create one Sensor resource
  • 106. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Use two collectors to define the measurement activiy
  • 107. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Associate two metric mixins to the Collector X
  • 108. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure And another two metric mixins to the Collector Y
  • 109. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Associate two aggregator mixins to the Sensor
  • 110. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure One publisher is going to use raw data from the collector
  • 111. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Another is going to receive measurements from the aggregators
  • 112. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure A frame for Collector X and its mixins
  • 113. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure ... one for Collector Y...
  • 114. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure ... one for the sensor
  • 115. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure The scope of the Sensor (for hook labels)
  • 116. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding the aggregators: a,b,d are hook labels
  • 117. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding publisher 2: aggregated (f,g) and raw data (e)
  • 118. OCCI monitoring extension Augusto Ciuffoletti Step by step design of a monitoring infrastructure Feeding publisher 1: measurement stream b is multicast
  • 119. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 120. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 121. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 122. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 123. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 124. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 125. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 126. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 127. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 128. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure
  • 129. OCCI monitoring extension Augusto Ciuffoletti Conclusions I To manage cloud resource, we need to monitor them I indeed many providers offer monitoring as a service I We establish a minimum common ground for interoperability I a standard, aligned with the Open Cloud Computing Interface I Two entities: I Collector link to produce monitoring data I Sensor resource to aggregate and deliver monitoring data I Finalized using mixins defined by the provider I Can be combined to form complex monitoring infrastructures I More... may be extended to any computational infrastructure End of part 1
  • 130. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti From the OCCI to Java: unfolding the infrastructure A Java backend for OCCI monitoring Augusto Ciuffoletti Dept. of Computer Science - Univ. of Pisa September 5, 2014
  • 131. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 132. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 133. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 134. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 135. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 136. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 137. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 138. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 139. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 140. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An experiment to verify an abstract specification The framework I Limited to the backend, in the perspective of the provider that implements the monitoring service I No user interface: OCCI-JSON documents are already on 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 monitoring framework? 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 interesting has been discovered...
  • 141. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 142. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 143. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 144. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 145. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 146. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 147. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 148. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Basic design options I The Collector Endpoint mixin is implemented on a compute resource as a daemon with an RMI interface I Metric mixins are dynamically created threads (Java reflection) I Metric classes are not dynamically loaded (todo) I The Sensor runs on a distinct host, possibly shared with other Sensors I Data flow from the Collector Endpoint to the Sensor uses a TCP channel with JSON encoding I Aggregator and Publisher mixins are dynamically created threads (as for Metrics) I communication between Aggregators and Publishers uses internal pipes and JSON I input and output hook attributes are respectively associated with PipedInputStreams and PrintWriters
  • 149. From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
  • 150. From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
  • 151. From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
  • 152. From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
  • 153. From the OCCI to Java: 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 for JSON. You can use JSON.simple to encode or decode JSON text. I jsoup 1.7.3 jsoup is a Java library for working with real-world HTML. It provides a very convenient API for extracting and manipulating data, using the best of DOM, CSS, and jquery-like methods.
  • 154. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti An example: monitoring load and connectivity of a Compute resource I The measurement of the average CPU load is sent outside the cloud as a UDP flow I The connectivity with the gateway is collected in a log file on the sensor.
  • 155. From the OCCI to Java: 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" }
  • 156. From the OCCI to Java: 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"] }
  • 157. From the OCCI to Java: 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": [] }
  • 158. From the OCCI to Java: 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 from the collectors
  • 159. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The sensor launches a Collector Manager thread for each collector in the scope
  • 160. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The Collector Manager invokes (by RMI) the measurement threads on the source I Each of them opens a TCP connection with the sensor socket
  • 161. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I The Collector Manager creates the pipes used for communication I There is one pipe for each hook label in the scope I Records from the socket are multiplexed to pipes according with hook identifiers
  • 162. From the OCCI to Java: 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
  • 163. From the OCCI to Java: 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
  • 164. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the sensor I One publisher is going to use raw data from the collector
  • 165. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The monitored resource runs a daemon with an RMI interface (MetricContainer) I The sensor has a TCP server-side port accepting connections I The sensor learns the RMI interface from OCCI documents
  • 166. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The CollectorManager on the sensor calls a remote LaunchMetric method on the metric container I The parameters include I the name of the metric mixin I the attributes of the mixin, encoded as a JSON object
  • 167. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The MetricContainer creates a metric thread (using reflection) I The metric thread opens a connection to the Collector socket on the Sensor
  • 168. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I All metrics associated with a Collector share the same TCP connection to the Sensor
  • 169. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Unfolding the Collector Endpoint I The messages from the metric to the Sensor are JSON documents, tagged with the destination hook
  • 170. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Finally, the experiment I A virtual network with guest + 3VM I One VM acts as “coordinator”, in fact simply holding the OCCI specs as application/occi+json documents in a web server I One VM acts as monitored resource I One VM acts as sensor container I The guest receives measurements through UDP
  • 171. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti On the sensor Launched by an external manager that allocates sensors to dedicated hosts
  • 172. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti On the monitored compute resource Launched as a consequence of the presence of a MetricContainer mixin
  • 173. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti On the web server I the CollectorEndpoint starts first I the Sensor downloads the documents that describe its scope (caching!)
  • 174. From the OCCI to Java: unfolding the infrastructure Augusto Ciuffoletti Conclusions of the experiment I The proof of concept still needs some work to be finished (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 blueprint for a real implementation
  • 175. From the OCCI to Java: 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” (into hook, or channel)
  • 176. From the OCCI to Java: 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” (into hook, or channel)