adfa, p. 1, 2011.
© Springer-Verlag Berlin Heidelberg 2011
Definición de Mecanismos Personalizados de Monitorización de Servicios Cloud
Priscila Cedillo, Javier Jimenez-Gomez, Silvia Abrahao, Emilio Insfran
Universitat Politècnica de València Camino de Vera s/n, 46022 Valencia, España
{icedillo, jajimgme, sabrahao, einsfran}@dsic.upv.es
Resumen. Actualmente muchas empresas están adoptando tecnologías cloud como solución de provisión de recursos tecnológicos, para sus necesidades de infraestructura y software. Como consecuencia de esto, se hace necesario contar con mecanismos de monitorización flexibles, que permitan tanto al cliente co- mo al proveedor, evaluar la calidad de los servicios ofertados con el fin de ofre- cer una adecuada provisión de los mismos. Existen muchas soluciones en el mercado para la monitorización de servicios desplegados en la nube. Sin em- bargo, la mayoría provee métricas simples, que no están directamente relacio- nadas a los Acuerdos de Nivel de Servicios (SLA) y tampoco cuentan con me- canismos personalizados, que permitan especificar nuevas fórmulas para el cálculo de métricas complejas. En trabajos anteriores, hemos propuesto una in- fraestructura de monitorización de servicios de software desplegados en la nu- be, que utiliza modelos en tiempo de ejecución, los cuales proporcionan un alto grado de flexibilidad a la hora de realizar cambios en los requisitos no funcio- nales a ser monitorizados, sin necesidad de parar el sistema de monitorización o realizar cambios sustanciales en la infraestructura. En este trabajo, extendemos la infraestructura propuesta, con mecanismos personalizados de monitorización de servicios, que permite hacer uso de información provista por la plataforma cloud, de herramientas de monitorización de terceros y de cálculos de métricas programados directamente en los servicios que están siendo monitorizados. Fi- nalmente, se muestra el uso de estos mecanismos personalizados para la moni- torización de servicios desplegados en la plataforma Microsoft Azure©.
1 Introducción
La adopción de Software as a Service (SaaS) provee grandes ventajas a sus usuarios, como por ejemplo la reducción de los costes iniciales de adquisición de software, el ahorro en costes de mantenimiento de los sistemas, el pago por uso de los recursos, la disponibilidad y el acceso fácil y rápido a la información entre otros. Sin embargo, resulta un desafío para los proveedores de servicios en la nube, el hacer frente a estas exigencias, las mismas que se encuentran especificadas a través de acuerdos de nivel de servicios (Service-Level Agreements – SLAs). Los SLAs son contratos en los que se acuerdan las mínimas garantías con las que un servicio será ofrecido a sus clientes, y que típicamente especifican las métricas con las cuales un proveedor puede medir su
nivel de cumplimiento [1]. Un fallo es penalizado mediante un crédito a favor del cliente, por lo que es necesario reducir la tasa de errores, para evitar pérdidas tanto por parte del proveedor de servicios, que tiene que hacer frente a las penalizaciones, como por parte de los clientes, a quienes puede impactar negativamente en sus activi- dades un fallo en el aprovisionamiento del servicio. Tanto clientes como proveedores, necesitan conocer si la calidad de sus servicios cumple con los umbrales esperados.
Para ello, se hace necesario contar con sistemas de monitorización, que permitan co- nocer en tiempo de ejecución, el estado de los servicios, ya sea para poder reaccionar ante una situación de fallo o para anticiparse a situaciones que puedan ocasionarlos.
En trabajos anteriores, hemos propuesto un proceso de monitorización para servi- cios de software en la nube [2] y un middleware que forma parte de la infraestructura de monitorización que soporta el proceso [3]. La solución utiliza modelos en tiempo de ejecución, lo que permite: i) añadir fácilmente nuevas características de calidad y métricas a ser monitorizadas, consiguiendo así un alto grado de escalabilidad, flexibi- lidad y mantenibilidad; ii) la adaptación de la infraestructura de monitorización a nuevas formas de recolección de información de calidad de los servicios. Además, en [3] hemos definido tres escenarios de recolección de datos y hemos realizado pruebas de monitorización en los dos primeros escenarios. En este artículo, nos centramos en estudiar a profundidad todos los escenarios en conjunto, poniendo énfasis en el tercer escenario (programación de envoltorios de servicios) e ilustrando su aplicación para la recolección de datos de calidad de servicios desplegados en plataformas cloud, los mismos que proveerán la extensibilidad necesaria a la infraestructura propuesta, para hacer frente a nuevas exigencias de monitorización. En este trabajo, también hemos considerado la necesidad de definir un cuarto escenario, el mismo que permitirá ex- tender nuestra solución haciendo uso de recursos provistos por terceras partes. Para ilustrar la utilidad de la solución propuesta, se presenta la monitorización de un servi- cio desplegado en Microsoft Azure©, haciendo uso del tercer escenario.
La estructura de este artículo es la siguiente: En la Sección 2 discutimos las solu- ciones existentes para la monitorización de servicios en la nube y sus limitaciones. En la Sección 3 presentamos un resumen de la infraestructura de monitorización. En la Sección 4 describimos los mecanismos personalizados de extracción de datos de mo- nitorización y aplicamos la solución propuesta a la monitorización de un servicio concreto. Por último, en la Sección 5, discutimos las conclusiones y trabajos futuros.
2 Trabajos Relacionados
En los últimos años se han propuesto varias soluciones comerciales y académicas para la monitorización de servicios en la nube. A continuación, discutiremos estas propues- tas, centrándonos en la forma en que los datos de monitorización son recolectados.
En cuanto a las soluciones comerciales, muchos proveedores de cloud públicas, ofrecen a sus clientes la habilidad de monitorizar servicios desplegados en la nube, mediante el uso de herramientas disponibles para la monitorización de CPU, almace- namiento y red [4]. A menudo, estas herramientas están estrechamente integradas con otras soluciones ofrecidas por el proveedor. Ese es el caso de CloudWatch [5], ofreci-
do por Amazon, como una herramienta de monitorización que permite a sus clientes gestionar y monitorizar sus aplicaciones residentes en AWS EC2. Así como otras herramientas comerciales, esta herramienta no provee información sobre la manera en que los datos de bajo nivel son recolectados y analizados, manteniéndolo en secreto.
Otra limitación es que se centran en monitorizar atributos de servicio de recursos hardware y carecen de la habilidad de monitorizar atributos relacionados con el SLA.
GroundWork permite monitorizar cualquier tipo de dispositivo o entidad virtual en un centro de datos, haciendo uso de plugins para expandir la cobertura de monitoriza- ción. Sin embargo, no se pueden definir métricas a partir de métricas existentes o parámetros dados por la plataforma, sino únicamente utilizando medios externos, programados y ofrecidos a través de plugins. Monitis [6] es una herramienta que per- mite la monitorización de proveedores tales como Amazon, Rackspace y GoGrid. Su monitorización se centra mayoritariamente en recursos de hardware tales como me- moria o CPU, y la captura de información se realiza con información recogida por agentes, que a su vez utilizan la información provista por plugins.
En cuanto a las soluciones académicas, Emeakaroha et al. [7] proponen una arqui- tectura de monitorización llamada CASViD, para monitorizar y detectar violaciones de SLA a nivel de aplicación. La información a monitorizar es recolectada mediante servicios, que utilizan agentes y un protocolo SMTP. Katsaros et al. [8] presentan un sistema de monitorización, que facilita la autoconfiguración tanto del tiempo de muestreo, como de los parámetros de monitorización. Los autores proponen el uso de scripts para recolectar datos, sin embargo, no especifican claramente como los requi- sitos no funcionales (RNFs) son vinculados con la información recogida por los scripts, así como la interacción de los scripts con los servicios. Montes et al. [9] pro- ponen GMonE, una herramienta que busca cubrir todos los aspectos de monitoriza- ción de servicios en la nube. Los autores proponen el uso de plugins para recolectar información de bajo nivel recolectada desde los servicios y no tienen en cuenta otras herramientas que pueden ser provistas por la infraestructura (ej. Azure Diagnostics), o métricas indirectas, que pueden ser calculadas desde la información capturada sin necesidad de que los usuarios programen plugins adicionales. Por último, Povedano- Molina et al. [10] proponen una arquitectura de monitorización de plataformas cloud, denominada DARGOS. La arquitectura dispone de un agente de monitorización para recolectar estadísticas del uso de recursos. En resumen, con respecto a la recolección de información, muchas herramientas utilizan agentes y plugins, otras crean sus pro- pios medios de recolección de información y otras no proveen la información del método de recolección de datos. Sin embargo, ninguna de estas soluciones ofrece mecanismos personalizados de monitorización, para hacer un mejor uso de la infor- mación provista por diferentes recursos y mejorar la experiencia del usuario.
3 Infraestructura de Monitorización
La arquitectura de la infraestructura de monitorización, mostrada en la Figura 1, ha sido diseñada para soportar el proceso de monitorización definido en [2]. Esta infraes- tructura permite la especificación y configuración de los RNFs a ser monitorizados,
interactúa con los servicios en la nube para evaluar su calidad y mostrar su estado en tiempo de ejecución, y en caso de ser requerido, genera un informe con las violacio- nes del SLA. Para alcanzar estos objetivos, y proveer alta flexibilidad en la definición de RNFs, métricas y formas de extracción de información de los servicios desplega- dos en plataformas específicas, se ha definido una serie de componentes y artefactos, que utilizan modelos en tiempo de ejecución.
La infraestructura de monitorización tiene dos componentes principales: el confi- gurador de la monitorización y un middleware de monitorización y análisis. Para la operación del configurador es necesario definir un Modelo de Requisitos de Monitori- zación que contiene la lista de RNFs a ser monitorizados (ej., los incluidos en el SLA como también RNFs adicionales que se necesiten monitorizar), así como también sus métricas y operacionalizaciones. Para la definición de los RNFs, se ha utilizado y extendido el lenguaje de descripción de acuerdos de nivel de servicio (WSLA). A continuación, y también dentro del configurador, es necesario realizar un mapeo entre los RNFs a ser monitorizados y las fórmulas para capturar información desde los ser- vicios. Toda la información, tanto del mapeo como de las fórmulas a ser empleadas, forma parte del modelo en tiempo de ejecución, que será utilizado en el middleware de monitorización y análisis. El middleware de monitorización y análisis realizará el cálculo de los valores, a partir de la información de bajo nivel recolectada desde los servicios, utilizando diferentes formas de recuperación de información. Los valores resultantes son almacenados en una base de datos, que posteriormente podrá ser usada para reportar el cumplimiento del SLA, verificando los valores obtenidos frente a los umbrales establecidos por el proveedor de servicios o para realizar cálculos sobre datos históricos.
Fig. 1. Infraestructura de Monitorización
4 Mecanismos de Recolección de Datos
El middleware de monitorización y análisis es el encargado de recolectar información desde los servicios desplegados en la nube. Para ello, hemos establecido diferentes escenarios de captura de datos, que permiten obtener información de calidad de bajo nivel de los servicios, explotando distintos mecanismos, lo que hace que la infraes- tructura propuesta sea flexible y extensible. Los mecanismos de captura de informa- ción se muestran en la Figura 2. En [3] hemos definido una primera aproximación a
Cloud Services
Monitoring & Analysis Middleware Monitoring Configurator
Monitoring Requirements
Model
Raw Data Counters SaaS Quality
Model
Runtime Quality Model
Analysis Engine
Measurements Engine
Service Quality Raw Data
Monitoring Infrastructure
List of Raw Data Counters
NFRs Violations Report SLA+Additional
NFRs
estos mecanismos y los hemos dividido en escenarios concretos, sin embargo nos centramos en el primero y segundo escenario. En este trabajo, haremos hincapié en el tercer escenario y plantearemos un cuarto escenario para futuros trabajos.
Fig. 2. Escenarios de Captura de Información
El primer escenario (Figura 2 (a)) se basa en la idea de utilizar mecanismos propios de la plataforma que extraen información de calidad de los servicios, a través de libre- rías u otros servicios disponibles, proveyendo acceso directo a datos de calidad de servicio a través de contadores, y que se corresponden directamente con las métricas especificadas en el Modelo de Requisitos de Monitorización. Este es el caso, por ejemplo de Diagnostics en Azure, que extrae y almacena datos de calidad de los ser- vicios, por medio de Performance Counters provistos por el servicio Diagnostics.
Estos contadores almacenan información cada cierto período de tiempo que puede ser especificado por el usuario. Los contadores pueden ser propios de la plataforma o personalizados. Los valores de monitorización de este escenario son almacenados en la tabla WADPerformanceCounters definida por Azure.
El segundo escenario (Figura 2 (b)) ocurre ante la necesidad de realizar cálculos en base a los contadores del primer escenario o recursivamente de este escenario, a fin de calcular una métrica. En términos de calidad, podríamos ver este escenario como la definición y aplicación de métricas indirectas e indicadores (mediante la agregación de otras métricas directas). Los cálculos son realizados por la máquina de medición que es un componente del middleware de monitorización y análisis. Este método de recolección de información da lugar a los Calculated Counters que se muestran en la Figura 2 (b) y que son almacenados en la tabla Calculated Metrics.
El tercer escenario permite la programación de envoltorios de servicios, extendien-
Monitoring & Analysis Middleware
Platform Data Retrieval Mechanism
Performance Counters
Custom Performance Counters
Storage
Direct Counters Table / Log Files Calculated Metrics Table
Service
Measurements Engine Analysis Engine
Monitoring & Analysis Middleware
Platform Data Retrieval Mechanism
Performance Counters Custom Performance
Counters
Storage Calculated Metrics Table
Service
Measurements Engine Analysis Engine
Calculated Counters
Direct Counters Table / Log Files
Monitoring & Analysis Middleware
Platform Data Retrieval Mechanism
Storage Calculated Metrics Table
Service
Measurements Engine Analysis Engine
Metrics Counters
Wrapper
Monitoring & Analysis Middleware
Platform Data
Retrieval Mechanism Storage
Calculated Metrics Table
Service Measurements Engine Analysis Engine
Metrics Counters
APIs, Plugins, Tools ...
(a) (b)
(c) Connector (d)
do los servicios con funcionalidades que permiten generar o extraer información de monitorización de los servicios en la nube que no sea posible obtener utilizando los dos primeros escenarios. En la Figura 2 (c) se muestra el escenario de captura de in- formación haciendo uso de envoltorios. Una vez que la información de monitoriza- ción es extraída, se la puede considerar como un contador del primer escenario (si su valor corresponde a la métrica a monitorizarse) o del segundo (si se realizará cálculos sobre dicha información). Finalmente, el cuarto escenario está relacionado con la utilización de herramientas de terceros (conectores, APIs, etc.) para recolectar infor- mación de los servicios (ver Figura 2 (d)). En este caso, los datos son capturados de dichas fuentes y mediante un servicio conector, la información es recuperada y alma- cenada en la tabla de métricas capturadas. Al igual que en el tercer escenario, se podrá recurrir al escenario (a) o (b) dependiendo del caso de cálculo de las métricas. Como ejemplo del escenario (d) podemos citar a Amazon CloudWatch, que guarda archivos log con datos de monitorización y permite almacenar y acceder a archivos log de instancias Amazon Elastic Compute Cloud (EC2), y en el cual tomaremos la informa- ción de los logs mediante el conector y los almacenaremos los datos en la tabla de métricas calculadas.
4.1 Contexto de Monitorización
Para ilustrar los escenarios de monitorización, hemos establecido un dominio que demande RNFs propios de ambientes cloud y hemos aplicado la monitorización sobre uno de sus servicios más significativos.
En este contexto, hemos definido un sitio de subastas en línea. Su modelo de ne- gocio es un proceso que permite comprar y vender mercancías o servicios a través de pujas, asignándolas al mejor postor. Estos sitios necesitan contar con una serie de características de calidad, entre las cuales se contemplan altos niveles de disponibili- dad, elasticidad, precisión, etc. Los servicios de subasta vienen en diferentes forma- tos, siendo los más populares las subastas directas (ascendentes) e inversas (descen- dentes). En la Figura 3, se muestra el modelo de negocio que hemos elegido para ilustrar la utilidad de la presente propuesta: un sitio de subastas ascendentes en el que los usuarios para realizar una puja deben contar con créditos que pueden ser adquiri- dos a través de un proceso de compra on-line. Cuando un usuario realiza una puja, se espera un tiempo durante el cual otro usuario podrá mejorar la misma. Si esto no ocu- rre, y el tiempo ha transcurrido, el producto motivo de la subasta, será adjudicado al usuario que realizó la puja. Una vez terminada la subasta, el vencedor mediante un servicio de pago ofrecido por una entidad financiera puede realizar el pago de la subasta. Cada vez que se realice una puja, los créditos del usuario son descontados, y una vez que estos se terminen, podrá adquirir más crédito y realizar más pujas. De los servicios que intervienen en esta aplicación, hemos elegido el servicio de pujas para monitorizarlo. En este caso, nos centramos en aplicar el proceso de monitorización a un RNF para el cual se tenga que utilizar el tercer escenario como medio de captura de información, ya que este escenario aún no ha sido abordado en nuestros trabajos previos. Para el proceso de monitorización, hemos establecido dos perfiles de stakeholders: (1) la persona que definirá el plan de monitorización, quien puede ser el
usuario, el proveedor de los servicios o las partes de soporte definidas en el SLA [11];
(2) la persona que establecerá la configuración de la monitorización en base al plan de monitorización, quien debe tener un entrenamiento previo del uso del configurador y conocimiento acerca del establecimiento de las métricas y su vinculación a los RNFs a ser monitorizados con el fin de generar el modelo en tiempo de ejecución.
Fig. 3. Modelo de Negocio del Sitio de Subastas On-line
4.2 Aplicación del Escenario de Recolección de Datos
Para ilustrar la definición y monitorización de RNFs utilizando el escenario 3, hemos seleccionado la Precisión de la Marca de Tiempo del Servicio (Service Timestamp Accuracy). Muchas aplicaciones deben almacenar cuidadosamente las marcas de tiempo para el propósito de facturación, cumplimientos regulatorios y sistemas de gestión que utilizan las marcas de tiempo secuenciales y cronológicas [12]. Entonces, marcas de tiempo erróneas pueden producir un fallo cronológico de la secuencia de operaciones/eventos. En el contexto de las pujas en línea, monitorizar las marcas de tiempo es un factor crítico ante la presencia de posibles errores, quejas o fallos del sistema, debido a que en este dominio se requiere mucha precisión en determinar quién ganó la puja y el momento exacto en el que lo hizo. En este caso, el SLA inclui- rá dentro de sus términos la siguiente cláusula: “No existirán más de 50 registros por millón que tengan marcas de tiempo imprecisas en más de 100 milisegundos”.
4.2.1 Configuración de la Monitorización
En esta tarea realizaremos la configuración de los RNFs a ser monitorizados para utilizarlos en el middleware de monitorización y análisis presentado en la Sección 3.1.
Para ello, se han definido las siguientes sub-tareas: (a) Establecimiento de los requisi- tos de monitorización; (b) Selección de los atributos de calidad; (c) Selección de las métricas de calidad; (d) Mapeo de las métricas; (e) Generación del modelo en tiempo de ejecución. La siguiente interfaz muestra el configurador que permitirá llevar a cabo las tareas de configuración de la monitorización. En la Figura 4 se presenta la parte representativa de este ejemplo en las que se generan las fórmulas que formarán parte del modelo en tiempo de ejecución, y que servirá como entrada para la siguiente tarea.
En primer lugar, se define el nombre de la operacionalización (1) que nos permi- tirá para recolectar la información para medir el RNF de interés (Precisión de la mar- ca de tiempo de servicio). A continuación, se escogen los Counters utilizados para calcular la fórmula asociada a esta operacionalización. De acuerdo a los escenarios propuestos en el apartado 4, se pueden emplear los Custom Performance Counters de Azure (2), relacionados al primer escenario, que son mecanismos propios de la plata- forma para la recolección de datos de monitorización de forma directa. Una combina-
2. Use credits to place a bid 1. Sign-up
and buy credits
3. Wait for the timer to reach 0
If someone bids, the time
restarts
If no one else bids, you are the winner!!!
ción de los mismos en una fórmula de cálculo, utilizando para ello el compositor de fórmulas (6) y la calculadora (7), se correspondería a la definición de Calculated Counters (4) del segundo escenario.
Fig. 4. Captura del Configurador
La última categoría de contador propuesta es la de tipo Wrapper/API Counters (8), relacionada con el tercer y cuarto escenario; estos datos son capturados desde los servicios mediante envoltorios o recursos de terceros, brindando a nuestra propuesta, un grado mayor de flexibilidad e interoperabilidad con otras herramientas. Asimismo, las operacionalizaciones (3) se pueden combinar entre sí recursivamente. Cada conta- dor de cualquier categoría puede ser utilizado en una fórmula de cálculo (ej. percenti- les, medianas, valor absoluto), seleccionando en esta ocasión el método Average para obtener la media de dichos valores en cada extracción. El valor numérico que lo acompaña representa la frecuencia en segundos de la extracción de dichos valores.
En este escenario, se ha empleado como contador de medición el valor asociado al Wrapper/API llamado Counter Average Timestamp Precision. Para ello, en el ser- vicio se ha definido dicho contador dentro de una categoría personalizada, utilizando el servicio Diagnostics de Microsoft Azure, concretamente la clase Performance Counters. El envoltorio del servicio se encarga de calcular los valores de este conta- dor (el error medido en la marca de tiempo y el número de marcas de tiempo utiliza- das) y es el motor de Diagnostics el encargado de transferir las mediciones al almace- namiento accesible para el motor de mediciones. Una vez terminada la configuración, se pulsará Add Operationalization (8) para añadirla al modelo en tiempo de ejecución.
4.2.2 Proceso de Medición
Para el proceso de medición es necesario definir previamente el envoltorio dentro del servicio a monitorizar, su principal función es recoger información propia del domi- nio del servicio. Por tanto, la programación de un envoltorio implica la creación de un método dentro del servicio que permita obtener la información necesaria y almacenar-
la en una fuente de datos accesible por el monitor y que debe ser especificada en el proceso de configuración; así, no es necesaria la modificación del middleware de monitorización. En este caso, el servicio extenderá su código, haciendo que se alma- cene la marca de tiempo con la que se ha registrado la puja, ésta será comparada con el tiempo universal coordinado (UTC), a fin de comprobar la exactitud de las marcas de tiempo cada vez que se presione el botón de “Pujar”. Así se tendrá información para calcular la métrica precisión de la marca de tiempo de servicio. Si tras la moni- torización se obtiene una violación en la marca de tiempo, ésta se verá reflejada en el reporte de violaciones del SLA, además, el usuario puede generar informes bajo de- manda sobre las mediciones o verlas en tiempo de ejecución. Esta información es de gran utilidad no solamente para medir la precisión de las marcas de tiempo, sino tam- bién para calcular otras métricas, como predicciones de escalabilidad, etc.
4.3 Discusión
Las ventajas de contar con los escenarios de recolección de información, no solamen- te van dirigidas a las diferentes formas de obtener datos de calidad de los servicios a monitorizar, sino además proveen un alto grado de flexibilidad, ya que permiten au- mentar el número y tipo de RNFs que pueden ser monitorizados. Esto sumado a la utilización de modelos en tiempo de ejecución, hace que la aproximación propuesta sea adaptable y que sea posible cambiar los parámetros de monitorización en tiempo de ejecución (sin necesidad de parar el servicio de monitorización). Por otra parte, la interoperabilidad que se puede alcanzar utilizando varios escenarios de captura de datos abre las puertas a la definición de mecanismos de parametrización y captura de información incluso de servicios provistos por terceros y que puedan impactar en el aprovisionamiento de los servicios protagonistas de la monitorización. Es importante además tener en cuenta el análisis de la cantidad de información a ser almacenada, la frecuencia de recolección y el tiempo en que los datos de monitorización persistirán, esto debido a que en plataformas cloud, tanto los servicios de almacenamiento como también las transacciones por servicio pueden incrementar los costes; de ahí, el dise- ñador de la monitorización debe sopesar su coste-beneficio.
5 Conclusiones y Trabajos Futuros
En este artículo hemos propuesto mecanismos personalizados de captura de informa- ción de monitorización de servicios en la nube, a través de la aplicación de varios escenarios, proveyendo flexibilidad y adaptabilidad a la infraestructura propuesta.
Además, hemos puesto en práctica la monitorización de un servicio en un dominio de subastas en línea, el cual demanda una característica de calidad propia de las plata- formas cloud. Los mecanismos de recolección de información han sido definidos teniendo en cuenta distintos escenarios de captura de información, los propios que proporcionan a la infraestructura la capacidad de utilizar librerías y herramientas de monitorización propias de la plataforma, la posibilidad de definir fórmulas de cálculo personalizadas para medir la calidad de los servicios, y la posibilidad de extender los servicios para que provean información de calidad.
Como trabajo futuro se pretende explorar la interoperabilidad de nuestro middle- ware con otras herramientas de monitorización de calidad de servicios por medio de conectores, APIs, etc. Esta interoperabilidad potenciaría nuestra propuesta de forma significativa, ya que el cálculo de métricas específicas para ciertos atributos de cali- dad puede requerir de un gran esfuerzo de desarrollo y sin embargo estar disponibles en la nube. Por otro lado, se estudiará el impacto económico del uso de diferentes fuentes de recolección de datos (ej. costos de utilizar herramientas de terceros, pro- gramación de APIs, envoltorios, etc), así como el costo de la comprobación del cum- plimiento del SLA. También se pretende validar la usabilidad/experiencia de usuario del uso de los mecanismos de monitorización en un caso de estudio más complejo.
Agradecimientos. Este trabajo de investigación está financiado por el proyecto Va- lue@Cloud (TIN2013-46300-R), el programa de Becas SENESCYT, Universidad de Cuenca, Ecuador y el programa Microsoft Azure for Research Award.
Bibliografía
[1] S. A. Baset, "Cloud SLAs : Present and Future", ACM SIGOPS Oper. Syst. Rev., vol.
46, no. 2, 2012, pp. 57–66, doi: 10.1145/2331576.2331586.
[2] P. Cedillo, J. Gonzalez-Huerta, E. Insfrán, and S. Abrahao, "Towards Monitoring Cloud Services Using [email protected]", 9th Workshop on [email protected], 2014, pp. 31–40.
[3] P. Cedillo, J. Jimenez-Gomez, S. Abrahao, and E. Insfran, "Towards a Monitoring Middleware for Cloud Services", 12th IEEE International Conference on Services Computing SCC, New York, USA, 2015 (to appear).
[4] K. Alhamazani, R. Ranjan, K. Mitra, F. Rabhi, P. P. Jayaraman, S. U. Khan, A.
Guabtni, and V. Bhatnagar, "An overview of the commercial cloud monitoring tools:
research dimensions, design issues, and state-of-the-art", Computing, 2014.
[5] A. W. Services, "Amazon CloudWatch Developer Guide API Version 2010-08-01 Amazon CloudWatch : Developer Guide", 2010.
[6] "Monitis", 2014. [Online]. Available: http://www.monitis.com/contact.
[7] V. C. Emeakaroha, T. C. Ferreto, M. A. S. Netto, I. Brandic, and C. A. F. De Rose,
"CASViD: Application Level Monitoring for SLA Violation Detection in Clouds", in 36th Computer Software and Applications Conf. (COMPSAC), 2012.
[8] G. Katsaros, G. Kousiouris, S. V. Gogouvitis, D. Kyriazis, A. Menychtas, and T.
Varvarigou, "A Self-adaptive hierarchical monitoring mechanism for Clouds", J.
Syst. Softw., vol. 85, 2012, pp. 1029–1041.
[9] J. Montes, A. Sánchez, B. Memishi, M. S. Pérez, and G. Antoniu, "GMonE: A complete approach to cloud monitoring", Futur. Gener. Comput. Syst., vol. 29, no. 8, Oct. 2013, pp. 2026–2040, doi: 10.1016/j.future.2013.02.011.
[10] J. Povedano-Molina, J. M. Lopez-Vega, J. M. Lopez-Soler, A. Corradi, and L.
Foschini, "DARGOS: A highly adaptable and scalable monitoring architecture for multi-tenant Clouds", Futur. Gener. Comput. Syst., vol. 29, no. 8, 2013.
[11] H. Ludwig and A. Keller, "Web Service Level Agreement (WSLA) Language Specification", 2003, pp. 1–110.
[12] E. Bauer and R. Adams, Service Quality of Cloud-Based Applications, vol. 18.
Hoboken, New Jersey, USA: John Wiley & Sons, Inc., 2013, p. 344.