detección y predicción de fallas a partir de métricas de
TRANSCRIPT
Detección y predicción de fallas a partir de
métricas de performance en sistemas Desktop
Cloud
Nicolás Gómez González
Jose Gabriel Tamura
Departamento de Ingeniería de Sistemas y Computación
Universidad de los Andes
Asesor: Harold Castro
Asesor: Jesse Padilla
Documento Proyecto de Grado
Bogotá, 2018
Resumen
La capacidad de utilizar la mayor cantidad de recursos computacionales disponibles, de manera confiable, debe
ser el objetivo final para cualquier organización interesada en reducir costos de operación, optimizar tiempos de
procesamiento e incrementar capacidad de almacenamiento. Por esta razón la Universidad de los Andes tiene
una implementación a la medida del modelo IaaS de Cloud Computing (unaCloud), que permite utilizar los
recursos ociosos disponibles en las salas de cómputo de manera oportunista y no intrusiva. A través de este
modelo de infraestructura como servicio se han logrado llevar a cabo proyectos de investigación de gran
demanda computacional y en áreas diversas como ingeniería civil, ingeniería industrial, bioinformática, entre
otras.
No obstante, unaCloud está soportada sobre una infraestructura no dedicada, heterogénea, volátil y distribuida.
Las anteriores características implican un riesgo asociado a los usuarios de las máquinas físicas, pues sus
procesos (que poseen prioridad) pueden cambiar de manera repentina la disponibilidad de los recursos físicos
del sistema. Asimismo, el hecho de trabajar sobre infraestructura distribuida supone retos de transmisión de
archivos, un manejo sobre la partición del disco, un protocolo de comunicación entre los agentes en cada
máquina física y un coordinador que gestione el estado del sistema, de las máquinas virtuales, de los clusters,
cada uno con sus respectivas configuraciones de red. En este escenario, garantizar la confiabilidad del sistema es
fundamental.
Este proyecto de grado pretende caracterizar el ambiente de unaCloud, modelar su estado general y detectar qué
errores se presentan y con qué frecuencia. Luego, se pretende usar dicho modelo para analizar, visualizar y
generar alertas sobre la condición del sistema de forma oportuna. Más allá, se busca desarrollar una herramienta
que permita tomar decisiones más inteligentes en tiempo real, que haga parte del sistema de asignación de
máquinas virtuales a máquinas físicas y sugiera probabilidades de fallo por dirección IP. Para lograr esto, se
implementarán nuevos agentes de recolección de métricas capaces de unificar medidas de hardware por
timestamp y reaccionar ante fallos de red. Así, un nuevo servidor de monitoreo analiza cada nuevo registro y
calcula la probabilidad de fallo asociada mediante un modelo de lógica difusa, alertando vía email las posibles
eventualidades. Finalmente, el pipeline termina en Kibana, una plataforma de dashboards que permite
interactuar con los registros, identificar riesgos y visualizar el rendimiento general a través del tiempo. El
objetivo final es reaccionar de forma inteligente ante condiciones anormales del sistema, para que el tiempo de
indisponibilidad de la plataforma sea mínimo. Los resultados demuestran que se hizo una aproximación que
satisface los objetivos generales del proyecto, pues se logró implementar una arquitectura robusta y escalable que
es capaz de responder a todos los eventos de todos los computadores que hacen parte de unaCloud, a un nivel de
detalle por segundo. El sistema de monitoreo también alerta y grafica sobre su estado y arquitectura.
Términos clave: Alertas, asignación inteligente, desktop cloud, estadisticas, monitoreo.
Índice
1. Introducción 4 1.1. Contexto 4
1.1.1. UnaCloud 4 1.2. Estado del arte 7
Amazon CloudWatch 7 Google StackDriver Monitoring 9 Monitoreo en UnaCloud 9
1.3. Objetivos del proyecto 10 1.4. Estructura del documento 10
2. Método 12 2.1. Agente de monitoreo 13
2.1.1 Monitoreo de recursos, estado de VirtualBox y estado de UnaCloud 14 2.1.2 Monitoreo de RTT y procesos que más recursos consumen 16 2.1.3 Monitoreo de una máquina en estado offline 18 2.1.4 Monitoreo de energía 19
2.2. Performance Collector Backend 20 2.2.1. Reconocimiento de errores en el sistema UnaCloud 25 2.2.2. Alertas y notificaciones 28 2.2.3. Reportes mediante queries 30 2.2.4. Política de shrinks 32
2.3. MongoDB 34 2.4. ElasticSearch y Kibana 35
3. Resultados 39 3.1. Comparación entre agente antiguo y nuevo agente 39 3.2. Dashboards 45 3.3. Alertas y reglas de lógica difusa 51
4. Discusión 52 4.1. Discusión de resultados 52 4.2. Trabajo futuro 53 4.3. Conclusiones 53
5. Bibliografía 55
1. Introducción
1.1. Contexto
Computación en la nube (Cloud Computing) es la entrega bajo demanda de capacidad de
procesamiento, almacenamiento, aplicaciones y otros recursos de TI a través de una plataforma de
servicios. Cloud Computing se destaca por proporcionar acceso rápido y confiable a dichos servicios,
con mínima gestión y a un bajo costo. Uno de los beneficios más grandes de Cloud Computing es el
hecho de que no es necesario tener infraestructura física ni contar con una inversión inicial, los
recursos que se utilizan pueden crecer o decrecer dependiendo de las necesidades computacionales a
la medida. Es decir, se tiene la posibilidad de aprovisionar con el tipo y el tamaño exacto de recursos
informáticos, y aumentarlos o decrecerlos según la demanda de los mismos en el ambiente de
producción. El usuario final tampoco se hace cargo del mantenimiento del hardware, ni de la
seguridad asociada al mismo, pues en los SLAs el proveedor Cloud asegura un servicio confiable
mediante virtualización, disponibilidad mínima al año, tiempos de respuesta por capacidad de red,
seguridad, aislamiento, entre otros.
Se han desarrollado varios modelos y estrategias de implementación para satisfacer las
necesidades de los distintos usuarios. Cada tipo de servicio en la nube y método de implementación
aporta distintos niveles de control, flexibilidad y administración [1].
Entre los modelos de implementación de Cloud Computing previamente mencionados se
encuentra el modelo Infrastructure as a Service (IaaS). Este modelo, como su nombre lo indica,
permite acceder y configurar infraestructura física (hardware) mediante servicios. Ofrece acceso a la
configuración de las características de red, a los equipos (virtuales o en software dedicado) y a espacio
de almacenamiento (disco). Este modelo proporciona el mayor nivel de flexibilidad y control de la
administración de los recursos de TI. Su mayor ventaja radica en ser altamente configurable, pero la
gestión y aprovisionamiento de software es delegada al consumidor del servicio.
1.1.1. UnaCloud UnaCloud es una implementación a medida del modelo IaaS de cloud computing, capaz de
entregar servicios computacionales fundamentales a través del uso oportunista de los recursos de
cómputo actualmente disponibles en el Campus de la Universidad de Los Andes.
A través de UnaCloud se han logrado llevar a cabo proyectos de investigación de gran
demanda computacional. Sus capacidades han sido utilizadas en proyectos de áreas como ingeniería
química, ingeniería industrial, bioinformática, entre otras. Un ejemplo concreto es “A Parallel Branch
and Bound algorithm for the Resource Levelling Problem with minimal lags” de ingeniería civil, que
pretende resolver grafos de 10^30 nodos, 100.000 nodos por segundo. El algoritmo hacía uso de
paralelización para resolver el problema de nivelación de recursos [6].
UnaCloud hace uso de la virtualización para desplegar instancias de máquinas virtuales de
forma individual y/o en clústeres sobre una infraestructura no dedicada, heterogénea, volátil y
distribuida soportada sobre equipos de escritorio en salas Waira y Alan Turing de la Universidad de
los Andes. El sistema utiliza los recursos sub-utilizados de estos equipos de forma oportunista siendo
no intrusivo con el usuario final. Es decir, mantiene los procesos de virtualización de UnaCloud en
una prioridad por debajo a los procesos del usuario.
Figura 1.1: distribución por sala de las máquinas físicas que prestan recursos a UnaCloud
Debido a su naturaleza oportunista y no intrusiva, es común que una instancia de máquina
virtual desplegada por UnaCloud pierda recursos computacionales como CPU, RAM, Disco o Red.
Esto ocurre cuando el sistema operativo que corre sobre la máquina física que soporta dicha máquina
virtual aumenta el consumo de alguno de estos recursos, o cuando varias máquinas virtuales compiten
por los mismos dentro del sistema. Cuando un recurso se agota, el hipervisor encargado de gestionar
las máquinas virtuales puede presentar fallas y la interacción de la máquina virtual y la máquina física
se ve comprometida.
Figura 1.2: representación gráfica del entorno de UnaCloud a escala
Actualmente, UnaCloud está desarrollando un sistema de tolerancia a fallos a través de un
protocolo de Snapshots globales que permiten guardar el estado de las máquinas virtuales que hacen
parte de un mismo sistema distribuido y de su red en un instante de tiempo determinado. Este
protocolo permite recuperar un sistema distribuido después de que ocurrió un fallo, es decir, lo
reconstruye después de que el fallo se presentó y afectó al sistema [5].
Sala Waira Computer Room Alan Turing Computer Room
Numero de computadores 78 desktops 39 desktops
RAM 32 GB 64 GB
Disco 1 TB Hard Disk 1 TB Hard Disk
Tarjeta gráfica Video: Intel HD Graphics 630 Nvidia Quadro P600 Graphics
Tarjeta de red Intel 1 Gb/s Intel 1 Gb/s
Sistema operativo Microsoft Windows 10
Enterprise
Microsoft Windows 10
Enterprise
Tabla 1.1: Descripción detallada de las características de hardware de las máquinas físicas que prestan recursos a
UnaCloud
1.2. Estado del arte
El monitoreo de sistemas distribuidos y aplicaciones desplegadas en la nube se está
convirtiendo en un aspecto cada vez más importante del desarrollo y mantenimiento de aplicaciones.
Como se mencionó anteriormente, monitorear un sistema permitirá identificar tendencias en su
comportamiento, comparar el desempeño de diferentes implementaciones, generar alertas, construir
dashboards y reducir costos de operación. Tener acceso a todos estos recursos es muy valioso, por lo
cual actualmente se da mucha prioridad al monitoreo, y existen varios servicios que lo facilitan.
Para sistemas desplegados en servicios cloud como AWS o Google Cloud, los mismos
proveedores ofrecen servicios de monitoreo, los cuales se describirán en más detalle a continuación.
Amazon CloudWatch
Amazon Cloudwatch es un sistema de monitoreo y manejo de servicios construido para
desarrolladores, operadores de sistema, ingenieros de calidad y administradores de TI. CloudWatch
proporciona a sus usuarios datos y descubrimientos para monitorear sus aplicaciones, entender y ser
capaz de responder a cambios de rendimiento en el sistema, optimizar la utilización de recursos, y
tener una vista unificada de la salud operacional. Los datos obtenidos del monitoreo y la operación de
la aplicación se almacenan en forma de logs, métricas, y eventos. Utilizando CloudWatch se pueden
establecer alarmas con gran cantidad de detalle, visualizar los logs y las métricas, definir acciones
automáticas, y descubrir posibles optimizaciones para la aplicación, todo esto con el fin de garantizar
de la que aplicación se está ejecutando sin problemas [3].
Figura 1.3: representación gráfica del servicio ofrecido por CloudWatch, Amazon. Imagen tomada de [3]
CloudWatch, al igual que la mayoría de los servicios que ofrece Amazon, no tiene un costo
mínimo o cuota inicial, se paga únicamente lo que se utilice de manera mensual. Se estima que para la
arquitectura de UnaCloud, con 128 máquinas, cada una reportando métricas una vez por minuto, tres
dashboards y aproximadamente 10 alarmas, el costo total de utilizar CloudWatch sería
aproximadamente $145.00 dólares mensuales, que se pueden ver más detalladamente en la tabla 1.2.
Recurso Cantidad estimada Costo mensual
Máquinas reportando métricas
una vez por minuto
128 ~$1.00 * 128 = ~$128.00
Dashboards 3 $3.00 * 3 = $9.00
Alarmas 10 $0.30 * 10 = $3.00
Almacenamiento 5 GB ~$1.00 * 5 = ~$5.00
Total ~$145.00
Tabla 1.2: estimación de costos mensuales de implementar el servicio CloudWatch de Amazon en UnaCloud.
Datos tomados de [2, 3]
Google StackDriver Monitoring
StackDriver Monitoring le da visibilidad a aspectos de performance, disponibilidad, y salud en
general de aplicaciones basadas en la nube. StackDriver recolecta métricas, eventos y metadatos de
Google Cloud Platform, Amazon Web Services, instrumentación de aplicaciones, y componentes
comunes como Cassandra, Nginx, Apache Web Server, Elasticsearch, entre otras. La información que
StackDriver consume luego sirve para crear dashboards, gráficas y alertas. [4]
A diferencia de CloudWatch, StackDriver Monitoring cobra de acuerdo a la cantidad de
información que se quiera almacenar y las llamadas a la API que permite guardar y recuperar esta
información. Un estimado de lo que costaría implementar StackDriver Monitoring en UnaCloud se
muestra en la tabla 1.3. Se puede observar que es considerablemente más costoso que CloudWatch, a
pesar de proporcionar servicios similares.
Recurso Cantidad estimada Costo mensual
Llamadas al API ~5,500k $0.01 * 5,500 = $55.00
Almacenamiento 5 GB ~$60 * 5 = $300.00
Total ~$355.00
Tabla 1.3: estimación de costos mensuales de implementar el servicio StackDriver Monitoring, de Google en
UnaCloud. Datos tomados de [2, 4]
Monitoreo en UnaCloud
El monitoreo sobre el sistema de UnaCloud previo a esta tesis es bastante limitado. Se cuenta
con un agente desarrollado en Java que aprovecha los logs de cuatro aplicaciones diferentes con el fin
de enviar un reporte unificado cada cierto tiempo, en el cual se incluye información sobre los recursos
de la máquina como CPU, RAM, estado de la red, procesos que se están ejecutando, y el consumo de
energía.
Las cuatro aplicaciones externas que se utilizan son
1. Sigar v1.6.3
2. Intel PowerGadget v3.0
3. Open Hardware Monitor v0.7.1 Beta
4. Perfmon
Las principales desventajas de este agente es que aprovechaba los logs generados por estas
plataformas, lo cual implica parseo y análisis de estos logs. Adicionalmente, el agente tenía problemas
unificando los timestamps de todas las lecturas a las diferentes aplicaciones externas. El problema de
los logs conducía a que el agente de monitoreo generara una carga extra sobre el disco de las máquinas
de UnaCloud, por lo cual el agente no podía estar corriendo constantemente sobre todas las máquinas.
Actualmente el sistema de monitoreo no se ejecuta nunca en las máquinas de UnaCloud., y los
datos que este monitor recolectó eran almacenados en una base de datos Mongo que ya no está
disponible. Se puede decir que hasta el momento, UnaCloud no tiene implementado un sistema de
monitoreo.
1.3. Objetivos del proyecto
Este proyecto de grado pretende caracterizar el ambiente de unaCloud, modelar su estado
general y detectar qué errores se presentan y con qué frecuencia. También se pretende usar dicho
modelo para analizar, visualizar y generar alertas sobre la condición del sistema de forma oportuna.
Más allá, se busca desarrollar una herramienta que permita tomar decisiones más inteligentes en
tiempo real, que haga parte del sistema de asignación de máquinas virtuales a máquinas físicas de
UnaCloud y sugiera probabilidades de fallo por IP. El objetivo final es reaccionar de forma inteligente
ante condiciones anormales del sistema, para que el tiempo de indisponibilidad de la plataforma sea
mínimo. Siendo así, los objetivos específicos de este proyecto son:
1. Recopilar datos sobre el uso de los recursos de cada máquina física en tiempo real. Estos datos
no deben perderse ante eventualidades de red.
2. Implementar un pipeline capaz de recibir los datos, procesarlos y presentarlos en un
dashboard intuitivo y fácil de interpretar.
3. Crear políticas de alerta sobre el sistema, y notificar en tiempo real cualquier problema en el
ambiente de UnaCloud.
4. Desarrollar un sistema de predicción capaz de sugerir qué máquinas físicas son las más
apropiadas para levantar una nueva máquina virtual, aprovechando los datos recolectados.
1.4. Estructura del documento
Lo que resta de este documento se organiza así: el capítulo 2 expone el método, donde se
describe el proceso que se sigue para desarrollar tanto el agente de monitoreo como el servidor que
recibe, almacena y procesa los datos. Esto incluye una descripción detallada de cómo se usan las
herramientas desarrolladas y de todas las variables que el agente reporta, el procesamiento que se
realiza a estos datos, y las alertas, dashboards, y reportes que se construyen a partir de los mismos.
Después, en el capítulo 3 se mostrarán comparaciones de desempeño entre el agente anterior y el
nuevo, el desempeño del servidor principal, de la base de datos Mongo, de ElasticSearch y Kibana, y
los descubrimientos que se pueden hacer utilizando los diferentes dashboards y reportes disponibles.
Finalmente, en el cuarto capítulo se discutirá lo que significa para UnaCloud contar con un sistema de
monitoreo y alertas, del trabajo futuro y las conclusiones de este proyecto.
2. Método
Con el fin de cumplir los objetivos propuestos, se propone la arquitectura en la figura 2.1.
Figura 2.1: arquitectura propuesta para la solución
Cada máquina física cuenta con un agente de monitoreo, que es ubicado al mismo nivel que
los agentes de UnaCloud. Dependiendo de la configuración del agente, éste está en capacidad de
mandar métricas de performance al más alto nivel de detalle al servidor principal. El servidor principal
es el encargado de orquestar los datos entrantes, transformarlos, analizarlos y guardar en las
respectivas bases de datos el payload final. A través del módulo de lógica difusa, el Performance
Collector Backend calcula en tiempo real la probabilidad de riesgo por máquina física y los datos
pueden ser consultados de la misma manera gracias al monitor de Kibana, conectado a ElasticSearch.
Para lograr la arquitectura propuesta, se dividió el desarrollo en varios pasos. En primer lugar,
se espera construir un pipeline robusto de extracción, transformación, almacenamiento y
visualización de datos a la medida usando la arquitectura propuesta por ELK; ElasticSearch, LogStash,
y Kibana. ElasticSearch es un motor de DB distribuido, RESTful, basado en JSON, muy escalable y
optimizado para búsquedas sobre series de tiempo. Logstash es un sistema distribuido de colas de
mensajes para transformación y análisis de logs. Kibana es una herramienta de monitoreo y
visualización a la medida, que permite generar alertas y validar reglas sobre la DB en tiempo real.
Para que el pipeline funcione de la manera esperada, es necesario desarrollar un nuevo agente
de monitoreo. Este debe ser un programa pequeño y liviano capaz de correr en todas las máquinas que
hacen parte de UnaCloud sin que cause interferencias con otros procesos que se estén ejecutando
sobre esas máquinas.
Como último paso, se planea implementar un servidor que esté en constante comunicación
con el pipeline ELK y desarrolle un modelo predictivo que se entrena a partir de cada caso en el que se
presenta una falla en las máquinas físicas. El modelo implementado debe utilizar un algoritmo de
clasificación que se escogerá una vez se tenga más información sobre los datos y las condiciones bajo
las cuales se trabajarán. Algunos buenos candidatos son Random Forest, Support Vector Machine
(SVM), y k-Nearest Neighbors (kNN). Este servidor puede ser desarrollado de manera local o se
puede desplegar junto con el pipeline ELK aprovechando la funcionalidad X-Pack que ofrece Elastic.
Este modelo se utilizará para determinar si los registros que llegan al pipeline indican que se
presentarán fallas, caso en el cual se deberían redistribuir las máquinas virtuales, o por lo menos tener
esta información en cuenta a la hora de desplegar nuevas máquinas. Dado que se espera una gran
cantidad de registros, también es necesario establecer ciertos thresholds a partir de los cuales se
considera riesgoso un registro y se evalúa contra el modelo, con el fin de no sobrecargar el sistema
evaluando todos los registros.
2.1. Agente de monitoreo
El agente de monitoreo es una aplicación desarrollada en Python con el propósito de ser ligero.
Se empaqueta como un ejecutable que puede ser distribuido fácilmente a todas las máquinas que
hacen parte de UnaCloud. Se ejecuta mediante la línea de comandos y puede recibir como parámetros
varios atributos que modifican su funcionamiento. A continuación se describe en detalle las
diferentes implementaciones que hubo y todas las capacidades del agente.
La mayoría de las funcionalidades del agente de monitoreo las proporciona una librería
llamada psutil, corto para “python system and process utilities”. Esta librería es multiplataforma y
permite recuperar información sobre utilización del sistema (CPU, RAM, discos, red) y los procesos
que están corriendo sobre el mismo [7].
2.1.1 Monitoreo de recursos, estado de VirtualBox y estado de UnaCloud
Como se mencionó previamente, utilizando psutil fue posible obtener información sobre los
recursos relevantes del computador: CPU, RAM, espacio en los discos e información de red. En la
figura 2.2 se puede ver un ejemplo de un mensaje que envía una máquina al servidor. A continuación
se describe más a fondo cada campo diferente a los ya mencionados.
● timestamp: Tiempo (en milisegundos) en el que se genera el mensaje para ser enviado al
servidor.
● ip: IP de la máquina que envía el mensaje. Dado que las máquinas de las salas en cuestión
cuentan cada una con una IP pública, este campo sirve como identificador de la máquina que
envía el mensaje.
● vms: Cantidad de máquinas virtuales que existen en la máquina. Se obtiene mediante
comandos de VBoxManage.
● running_vms: Cantidad de máquinas virtuales que existen en la máquina y están corriendo al
momento de obtener los datos. Al igual que el campo anterior, se obtiene mediante
VBoxManage.
● vbox_process_count: Cantidad de procesos con el nombre VBoxHeadless.
● vbox_status: Estado de los procesos VBoxHeadless. Se obtiene mediante psutil, y puede
tomar cualquier valor entre “running”, “sleeping”, “disk_sleep”, “stopped”, “tracing_stop”,
“zombie”, “dead”, “wake_kill”, y “waking”.
● uncloud_status: Estado del proceso correspondiente al agente de UnaCloud. Se obtiene
mediante psutil, buscando los procesos que estén utilizando el puerto 10027, y puede tomar
cualquier valor entre “running”, “sleeping”, “disk_sleep”, “stopped”, “tracing_stop”, “zombie”,
“dead”, “wake_kill”, y “waking”.
Todas las demás mediciones corresponden a recursos del computador a los que se puede
acceder fácilmente mediante psutil.
Figura 2.2: mensaje enviado por la versión 1.0 del agente de monitoreo
Esta primera versión del agente solo cumple con los requisitos más básicos, ya que se
desarrolló con el fin de probar la viabilidad del nuevo agente propuesto. A la hora de correr esta
versión del agente, es posible establecer tres parámetros que alteran su funcionamiento:
1. Frecuencia: La frecuencia en segundos con la que el agente envía mensajes al servidor.
Por defecto, este valor es 1 segundo.
2. Duración: Tiempo en segundos por el que el agente correrá. Si no se indica un valor
para este parámetro, el agente se ejecutará infinitamente.
3. Puerto de UnaCloud: Número correspondiente al puerto en el que está corriendo el
proceso de UnaCloud. Por defecto es el 10027, lo cual no debería cambiar.
2.1.2 Monitoreo de RTT y procesos que más recursos consumen
Para la segunda versión del agente, se implementaron la medición del RTT y de los procesos
que más recursos consumen. Adicionalmente, con el fin de reducir el tamaño total del mensaje que se
envía, se envía un mensaje adicional cuando inicia la ejecución del agente de monitoreo. Este mensaje
contiene información que no debería cambiar durante la ejecución; cosas como el número de núcleos
del procesador, las particiones de la máquina, y el total de ram, swap y disco con el que cuenta la
máquina. El otro mensaje que se agrega en esta versión del agente de monitoreo es el mensaje que se
envía con los procesos una vez se supera un umbral de cierto recurso. Este recurso puede ser el
porcentaje de RAM, el porcentaje de CPU, o el porcentaje de ocupación del disco. Una vez se supera el
umbral, se ordenan los procesos que más estén ocupando ese recurso y se retornan los primeros n,
donde n es una cantidad parametrizable cuyo valor por defecto es 5.
Adicional a lo anterior, el mensaje principal también es un poco diferente en la segunda
versión del agente de monitoreo. Un nuevo campo, rtt, aparece en cada mensaje que se envía, y
representa el “round trip time” de un ping estándar de Windows (4 mensajes de 32 bytes) desde cada
máquina física hasta el servidor principal de UnaCloud. Con esta medición, es posible determinar qué
tan congestionada se encuentra la red sobre la cual viajan las imágenes de las máquinas virtuales de
UnaCloud y demás archivos necesarios para el correcto funcionamiento del sistema. Con el fin de
generar una sobrecarga sobre la máquina física realizando pings a una frecuencia muy alta, la
frecuencia del ping no necesariamente es la misma con la que se envían los mensajes, y también es
parametrizable.
Figura 2.3: mensajes enviados por la versión 2.0 del agente de monitoreo. A la derecha está primero el mensaje inicial que se envía únicamente cuando comienza la ejecución del agente, y debajo se puede observar el mensaje
que se envía cuando un cierto recurso supera el umbral especificado. A la izquierda, el mensaje que se envía constantemente.
Como se mencionó anteriormente, esta versión cuenta con varios parámetros más que la
versión anterior, los cuales se describen a continuación.
4. Umbral de RAM: El valor máximo que puede tomar el porcentaje de RAM antes de
que se envíe un mensaje con los procesos que más están consumiendo este recurso.
5. Umbral de CPU: El valor máximo que puede tomar el porcentaje de CPU antes de que
se envíe un mensaje con los procesos que más están consumiendo este recurso.
6. Umbral de disco: El valor máximo que puede tomar el porcentaje ocupado de disco
antes de que se envíe un mensaje con los procesos que más están ocupando este
recurso.
7. Numéro de procesos a enviar: La cantidad de procesos que se quieren incluir en el
mensaje que es enviado cuando un cierto recurso supera el umbral.
8. Frecuencia del RTT: Frecuencia en segundos con la que se realizará el ping que mide
el RTT.
2.1.3 Monitoreo de una máquina en estado offline
La tercera versión del agente incluye una funcionalidad que permite saber cuando un
computador estuvo offline y por cuánto tiempo. Se determina que una máquina está offline si está en
ejecución y tratando de reportar pero por problemas de red, no es capaz de enviar sus mensajes. Una
vez la máquina deja de estar offline, envía un mensaje reportando por cuánto tiempo estuvo offline,
que se puede observar en la figura 2.4.
Figura 2.4: mensaje enviado por una máquina que estuvo offline por 12 segundos tras volver a estar online
2.1.4 Monitoreo de energía
La cuarta y última versión del agente incluye información sobre el consumo de energía de la
máquina física, utilizando una herramienta externa llamada PowerGadget.
Power Gadget es una herramienta de monitoreo del uso de energía habilitada para
procesadores Intel Core (de 2da a 7ma generación). PowerGadget incluye una aplicación, un driver, y
librerías que permiten monitorear y estimar en tiempo real el consumo de energía en vatios usando los
contadores de energía en el procesador [11].
Utilizando una herramienta complementaria de PowerGadget, llamada PowerLog, es posible
generar un archivo csv con las mediciones de energía del procesador y otras partes del hardware por un
periodo de tiempo determinado. De esta manera, la última versión del agente de monitoreo genera
estos logs cada cierto periodo de tiempo y envía junto con el mensaje principal información sobre el
consumo promedio durante el tiempo que se realizó la medición. En la figura 2.5 se puede observar la
información adicional en esta última versión del agente.
Figura 2.5: información sobre el consumo de energía que se anexa al mensaje principal
Al igual que con el RTT, la medición de la energía sucede con una frecuencia parametrizable
con el fin de no generar una carga computacional innecesaria sobre las máquinas físicas, el cual sería el
parámetro número 9 del agente de monitoreo.
2.2. Performance Collector Backend
El performance Collector Backend es una aplicación desarrollada en Node.js (Versión 8.12.0)
a través del framework para servidores web Express. Su funcionalidad principal es ofrecer una serie
de endpoints para que los agentes de monitoreo puedan guardar la información recolectada de las
métricas de performance, y los usuarios administradores de UnaCloud puedan realizar consultas
sobre el estado de las bases de datos, el estado del sistema y salud del mismo servidor. Adicionalmente,
el Performance Collector Backend es quien analiza los datos a través del módulo de lógica difusa,
quien sirve las alertas necesarias y transforma los datos para su correcto almacenamiento en las bases
de datos MongoDB y ElasticSearchDB.
La implementación del Performance Explorer Backend fue desplegada en una máquina física
disponible en el laboratorio de redes de la Universidad de los Andes con dirección IP 157.253.205.40,
en el puerto 3000. A continuación se describe el sistema operativo y características de hardware de
este computador, denominado “Server13”.
○ Sistema Operativo: Ubuntu V16.04 ○ Disco Duro: 512 GB ○ Memoria RAM: 16GB
La carga esperada que debe soportar esta máquina física es 128 agentes reportando
información de 2kb payload por segundo (si se considera el más alto nivel de detalle de recolección de
métricas). Se realizaron pruebas de carga y pruebas de estrés sobre esta máquina física para verificar
que la arquitectura del computador soportara la carga prevista anteriormente. Las pruebas se
realizaron a través de la herramienta JMeter, en un computador de las sala de Waira 1. Se definió un
ramp-up de 5 minutos, carga constante por 30 minutos y luego cool-down de 1 minuto. Después de
realizar las pruebas de carga se pudo comprobar que el servidor tolera carga de más de 300 peticiones
por segundo con 0% de error. Dada las necesidades del sistema, se consideró suficiente el
aprovisionamiento físico del servidor, y alternativas de escalamiento horizontal y vertical fueron
descartadas.
A continuación se describe en detalle la implementación, estructura del proyecto y todas las
capacidades del servidor.
Figura 2.6: Estructura del proyecto Performance Collector Backend
Cuando el servidor es desplegado, Node.js procede a ejecutar el archivo app.js, que es el
archivo que ofrece todos los endpoints y tiene la configuración de seguridad, puertos y manejo de
peticiones REST. Al mismo nivel de app.js se encuentra el package.json, que es el archivo en el cual se
encuentran todas y cada una de las librerías externas que usa el proyecto. Estas librerías son
gestionadas por el manejador de paquetes de JavaScript NPM (Versión 6.4.1) y en la carpeta
node_modules es donde quedan instaladas.
Bajo public/javascripts se encuentra el archivo manejador de las bases de datos, DB.js. Este
archivo contiene las direcciones IP del servidor MongoDB y del servidor ElasticDB, y crea un pool de
conexiones general para uso del servidor. Las direcciones IP de Mongo y Elastic están en el código de
este archivo. También, bajo public/javascripts se encuentra la carpeta Performance, que es el corazón
del servidor. En esta carpeta se encuentran todos los archivos que responden a las peticiones REST.
Bajo public/javascripts/Performance/Creators.js se resuelven todos los endpoints que crean
archivos a la base de datos MongoDB. En Creators.js se encuentran los métodos que resuelven,
descritos en más detalle en la tabla 2.1.
Endpoint Funcionalidad
/hardwareInfo Almacena los datos de las máquinas físicas con llave [ip] una sola
vez. Se guardan métricas como tamaño total de disco, tamaño total
de RAM, información no variable de CPU, etc.
/createMetric Almacena las métricas de performance de las máquinas físicas. Este
endpoint es el encargado de identificar casi todos los errores,
mandar métricas resumidas a ElasticSearch y almacenar en mongo
la info completa.
/recoveredData Almacena los metadatos cuando una máquina física almacena
métricas porque no tiene conexión. Va información como tiempo
total en la que estuvo desconectada y siempre genera email de
notificación de recuperación.
/processes Almacena los top 10 procesos que más están consumiendo una
métrica determinada cuando dicha métrica pasa un threshold de
50% de consumo.
/avgRTT Es un servicio que permite saber el estado de la red. Almacena el
promedio de los rtt. Devuelve un int.
/readMachines Es un servicio que permite saber la última métrica de performance
que ha reportado cada máquina. Se almacena en un hash en
memoria.
/readMachineByIp/:IP Es un servicio que permite saber el estado de una máquina en un
momento determinado.
Tabla 2.1: endpoints ofrecidos por el Performance Collector Backend para enviar información y guardarla.
Bajo public/javascripts/Performance/Deleters.js se resuelven todos los endpoints que
eliminan archivos a la base de datos. En Deleters.js sólo hay un método y permite eliminar un
documento de la base de datos MetricsCollection de Mongo, dado un ID especifico.
Bajo public/javascripts/Performance/Readers.js se resuelven todos los endpoints que
recuperan información sobre la base de datos MongoDB. En Readers.js se encuentran los métodos
que resuelven, que se pueden ver más en detalle en la tabla 2.2.
Endpoint Funcionalidad
/readHardwareInfo Permite leer los datos de hardware de una ip
específica. Retorna todos los documentos que estén
almacenados en esta colección.
/readMetrics Permite acceder a la base de datos de métricas, tanto
por IP como de forma general revisar todas las
métricas almacenadas de todas las IP.
/readrecoveredData Permite leer los metadatos de recuperación de red.
Posee información de tiempo de indisponibilidad
“time offline”.
/readProcesses Permite leer los procesos que más están consumiendo
un recurso escaso en un momento determinado.
Almacena IP y Timestamp.
/readErrors Permite leer la colección de errores, brinda
información sobre errores por ip detallada y reporta
el total del conjunto de ips que están reportando
métricas.
/avgRTT Es un servicio que permite saber el estado de la red.
Almacena el promedio de los rtt. Devuelve un int.
/readMachines Es un servicio que permite saber la última métrica de
performance que ha reportado cada máquina. Se
almacena en un hash en memoria.
/availableSpaceMachineUnacloudDisk/:IP Retorna un valor en GB de espacio disponible en la
partición dedicada a UnaCloud de una IP específica.
/ramPercentMachine/:IP Retorna el último reporte de porcentaje de uso de
RAM para una IP específica.
/cpuPercentMachine/:IP Retorna el último reporte de porcentaje de uso de
CPU para una IP específica.
/virtualBoxStatusMachine/:IP Retorna el último reporte del estado de virtualBox
para una IP específica.
/unacloudStatusMachine/:IP Retorna el último reporte del estado de unaCloud
para una IP específica.
Tabla 2.1: endpoints ofrecidos por el Performance Collector Backend para recuperar información.
Bajo public/javascripts/Performance/Updaters.js se resuelven todos los endpoints que
modifican archivos en la base de datos MongoDB. En Updaters.js se encuentran los métodos que
resuelven la política de shrink de reportes. Estos métodos serán explicados en su propia sección de
este capítulo.
Bajo public/javascripts/Performance/EmailNotification.js se resuelve el sistema de alertas vía
Email. En este archivo se hace uso de la librería NodeMailer, que provee servicios de correo. El
método principal se llama sendEmail. Este método recibe por parámetro el asunto y el mensaje que se
quiere mandar. La lógica detrás de la política de emails será explicada en su propia sección de este
capítulo.
Adicionalmente, el Performance Collector Backend maneja 5 colecciones en la DB Mongo:
1. Errores
2. Métricas
3. Reportes
4. Hardware
5. Recuperación
En la colección de Hardware se almacena la información de las máquinas físicas que no
cambia a través del tiempo. Información como tamaño total de disco, capacidad de red y número de
particiones son incluidas para evitar redundancia y repetición de datos por cada objeto en la base de
datos.
Figura 2.7: Ejemplo de objeto en la colección de información de hardware
En la colección de errores se almacenan todas las ocurrencias de uno de los seis tipos de
errores que pueden presentarse en el ambiente. También se almacena por ip el error y el timestamp del
evento. Estos errores y la distribución en la base de datos serán explicadas con más detalle más
adelante en este capítulo. En la colección de métricas se almacena toda la información que reportan
por frecuencia los agentes de monitoreo. A estos datos no se les realiza ninguna transformación. En la
colección de reportes son almacenados los resultados de hacer operaciones de shrink sobre un periodo
de tiempo en la base de datos. La política de shrink será explicada en la última sección de este capítulo.
Finalmente, en la colección de recuperación se almacena un objeto cada vez que una máquina física
estuvo un tiempo mayor a dos segundos sin conexión a red. Esta colección almacena la dirección IP y
el tiempo que una máquina estuvo offline (en segundos).
2.2.1. Reconocimiento de errores en el sistema UnaCloud
Se identificaron 6 tipos de errores que se pueden caracterizar en el ambiente de UnaCloud a
través de las métricas de performance que el agente de monitoreo recolecta. Cada uno de los tipos de
errores es explicado en la tabla 2.3.
Cada que se detecta un error, este es almacenado en la colección de error con el fin de tener
fácil acceso a las ocurrencias de cada error. La colección de errores puede observarse en la figura 2.8.
Error Metrica Descripción
unacloudIsNotResponding
unacloudIsNowResponding
0 -> fallo
1 -> recuperación
Esta métrica es obtenida del agente de monitoreo
y verifica que el proceso de unacloud en el host
tenga estado “running”. Manda al servidor 0 si el
proceso no está corriendo
virtualBoxIsNotResponding
virtualBoxIsNowResponding
0 -> fallo
1 -> recuperación
Esta métrica es obtenida del agente de monitoreo
y verifica que el proceso de virtualbox en el host
tenga responda a llamados por consola. Manda al
servidor 0 si el proceso no está corriendo.
diskIsFull
(disco de unacloud)
diskHasSpace
pct>80% -> fallo
pct<80% -> recuperación
Esta métrica se calcula en el backend. Cuando el
porcentaje de disco de la partición de unaCloud es
superior al 80%, se considera que el disco está
lleno.
busyNetwork
emptyNetwork
avgRTT*= rtt promedio de
todos las máquinas del sistema
newMetric.rtt > avgRTT * 3 -> fallo
newMetric.rtt < avgRTT * 3 ->
recuperación
Esta métrica se calcula en el backend. Se hace un
promedio ponderado entre todos los agentes de
monitoreo que están reportando RTTs. Se
considera que la red está congestionada cuando
una métrica de RTT es tres veces superior al
promedio ponderado.
shutDown
(tiempo que estuvo apagada la
máquina)
isOn
Revisa cada minuto [frecuency] si
hace 5 minutos [timeAccepted], la
ip n no ha notificado métricas ->
fallo
La ip vuelve a notificar
->recuperación
El backend posee un CRON que revisa cada cierto
intervalo de tiempo si una máquina ha dejado de
responder. Si dejó de responder, se asume que la
máquina fue apagada. Si la máquina se quedó sin
conexion y por esa razón dejó de responder,
cuando recupere su conexión notificará al
backend y este error pasará a ser
“noInternetConection”.
noInternetConection
(tiempo que estuvo
desconectada la máquina)
timeOffline
Si llega un mensaje a
/recoveredData
Cuando una máquina no notifica datos, se asume
que está apagada. Si el error no es que está
apagada sino que estaba sin internet, el agente
local guarda los datos local y cuando vuelve la
conexión entonces notifica al backend. La base de
datos de error entonces cambia los errores
shutDown por noInternetConection, por el
tiempo en el que el agente calculó que no tenía
conexión
Tabla 2.3: errores identificados en UnaCloud.
Figura 2.8: Objeto único en la colección de errores. Registra 6 tipos de error.
Figura 2.9: Vista al arreglo de máquinas en la colección de errores. Quedan registradas las horas en las cuales el
error se presentó por primera vez después de que se hubiera recuperado.
2.2.2. Alertas y notificaciones
Después de que el Performance Collector Backend detecta uno de los seis errores que se
explicaron en la sección anterior, se debe determinar si es necesario lanzar una alerta a la base de datos
de ElasticSearch, y si es necesario mandar una notificación vía correo electrónico al administrador de
UnaCloud. Una alerta es generada a través del modelo de lógica difusa que se definió para caracterizar
el estado normal y en riesgo de una máquina física del sistema, dadas sus métricas de performance en
un instante determinado.
Se definieron tres reglas de lógica difusa.
1. Disco: Función a trozos tipo trapecio con vértices 20, 90, 100, 100. El riesgo asociado al disco
retorna valores cada vez más elevados desde el 20 y en línea recta hasta 90. Si una métrica es
evaluada bajo esta condición y su valor está entre 90 y 100% de disco utilizado, el modelo
devuelve 1 (alto riesgo).
2. CPU: Función a trozos tipo trapecio con vértices 0, 90, 100, 100. El riesgo asociado a cpu es
más crítico que en disco, pues varía de forma más agresiva y afecta todos los procesos en la
máquina física. Retorna valores cada vez más elevados desde el 0 y en línea recta hasta 90. Si
una métrica es evaluada bajo esta condición y su valor está entre 90 y 100% de CPU utilizado,
el modelo devuelve 1 (alto riesgo).
3. RAM: Función a trozos tipo grade con vértices 0, 50, 100. El riesgo asociado a la RAM retorna
valores cada vez más elevados desde el 0 hasta el 100 de manera proporcional. Se pudo
evidenciar una correlación directa entre espacio disponible en disco y porcentaje de RAM
utilizado. Es por esto que esta regla está indexada con un operador AND a la regla de disco.
Los correos que se envían pueden tener tres asuntos diferentes; “Reporte”, “Error” o
“Recuperación”. Los emails con asunto Reporte se generan cada 3 horas, y reportan el estado de la base
de datos y el número de documentos en la misma. Los Emails con asunto Error son generados cuando
el servidor detecta que hay un comportamiento anormal en el sistema (errores y alertas explicados
anteriormente). Finalmente, los emails con asunto Recuperación son enviados cuando una IP se
recuperó de un error.
Error Metrica Alerta
unacloudIsNotResponding
unacloudIsNowResponding
0 -> fallo
1 -> recuperación
Se manda email de notificación
cuando llega por primera vez
“ [metrica] : [fallo]”
para la IP n y se guarda en la base
de datos de errores el error por ip
y el error conjunto del sistema.
Las x veces consecutivas que
llega [fallo], guarda en la base de
datos el error por ip y error
ponderado, pero no manda
email. (máx emails al día: 500)
Cuando la ip n reporta
[recuperación] para la métrica Y
ya se había mandado un email de
fallo, se manda correo de
notificación de recuperación.
virtualBoxIsNotResponding
virtualBoxIsNowResponding
0 -> fallo
1 -> recuperación
diskIsFull
(disco de unacloud)
diskHasSpace
pct>80% -> fallo
pct<80% -> recuperación
busyNetwork
emptyNetwork
avgRTT*= rtt promedio de todos las
máquinas del sistema
newMetric.rtt > avgRTT * 3 -> fallo
newMetric.rtt < avgRTT * 3 -> recuperación
shutDown
(tiempo que estuvo apagada la
máquina)
isOn
Revisa cada minuto [frecuency] si hace 5
minutos [timeAccepted], la ip n no ha
notificado métricas -> fallo
La ip vuelve a notificar ->recuperación
noInternetConection
Si llega un mensaje a /recoveredData
Cuando una máquina no notifica
datos, se asume que está apagada.
(tiempo que estuvo desconectada la
máquina)
timeOffline
Si el error no es que está apagada
sino que estaba sin internet, el
agente local guarda los datos local
y cuando vuelve la conexión
entonces notifica al backend. La
base de datos de error entonces
cambia los errores shutDown
por noInternetConection, por el
tiempo en el que el agente calculó
que no tenía conexión
Tabla 2.4: alertas configuradas para los diferentes errores que se pueden identificar.
2.2.3. Reportes mediante queries
Una parte fundamental de este trabajo es poder recuperar y visualizar la información que se
está recolectando. Existe un interés en visualizar y monitorear el estado del sistema de UnaCloud en
tiempo real, pero generar gráficas y reportes que tengan en cuenta todos los datos recopilados es una
ventaja a la hora de calcular estadísticas y concluir sobre el comportamiento esperado del ambiente en
general. A través de consultas a la base de datos es posible determinar tiempos de indisponibilidad por
sala por mes, o discriminar el porcentaje de uso por hora del día a través del tiempo de algún recurso.
Es por eso que se creó un proyecto aparte dedicado a construir scripts para hacer consultas sobre la
base de datos Mongo. A este proyecto se le dio el nombre DBQueries.
El módulo de reportes consiste en una serie de archivos JavaScript que se ejecutan utilizando
directamente el comando node [nombre del archivo].js. Existen cuatro archivos que, de manera
asíncrona, consultan a la base de datos para generar reportes de distintos tipos.
1. Insertar documentos en la base de datos
Este Script se creó para poder insertar un número ilimitado de documentos de prueba en la
colección de métricas en una base de datos Mongo local. Esto con el fin de hacer las pruebas de los
demás scripts sin dañar o modificar los datos reales hasta tener una versión estable.
2. Matriz de correlación
Este Script hace una consulta sobre la colección de métricas y filtra todos aquellos
documentos cuyas métricas de performance sean consideradas en “riesgo”, según lo definido en la
sección de este capítulo “Reconocimiento de errores”. Esto implica un filtro por varios campos sobre
una colección en MongoDB. Después analiza el estado de cada una de esas máquinas en riesgo justo
antes del fallo, y determina qué otra métrica fue relevante o influyó en dicho momento crítico. A
partir del análisis de resultados de este script se determinó que la RAM está directamente relacionada
con el Swap y también con el total de disco disponible. Este conocimiento se usó luego para generar las
reglas de lógica difusa.
3. Consumo de CPU por hora del día
Este Script hace consultas sobre la línea de tiempo de los datos. Debe tener en cuenta el
timestamp de cada métrica para hacer una correcta agrupación por hora del día de consumo de un
recurso específico. A través de este script fue posible generar un reporte de consumo promedio de cpu
con mayor nivel de detalle, pues está en la capacidad de calcular los cuartiles y discriminar mínimos,
máximos y outliers.
4. Consumo de RAM por hora del día
Este Script funciona exactamente igual que el de CPU, con la única diferencia siendo que
extrae datos sobre el porcentaje de consumo de RAM en lugar de CPU.
Estos scripts pueden servir de base para hacer toda clase de consultas a cualquiera de las 5
colecciones en la base de datos performance_collector_unacloud MongoDB, incluyendo aquellas
consultas con filtro de tiempo o estado de alguna métrica en particular.
Figura 2.10: Gráfica de consumo de cpu promedio en UnaCloud de 7am a 10pm
Figura 2.11: Boxplot de consumo de cpu promedio en UnaCloud de 7am a 10pm
2.2.4. Política de shrinks
El administrador del sistema de monitoreo está en la capacidad de generar reportes sobre la
base de datos MongoDB, específicamente sobre la colección de métricas. La colección de métricas
crece de manera indefinida debido a que se guardan los datos de performance de todas las máquinas
físicas en el más alto nivel de detalle (por segundo). A medida que pasa el tiempo, es normal que los
datos pierdan relevancia y mantenerlos con tan grado nivel de detalle es innecesario, pues el interés
está en los datos más nuevos y el histórico general.
Para evitar que la base de datos MongoDB se llene, el Performance Collector Backend definió
una política de Shrink, que genera reportes al nivel de detalle deseado sobre un cierto periodo de
tiempo, con el fin de poder luego eliminar los datos sobre los que ya se tiene un reporte. Se ofrece un
endpoint específico, que se puede observar en la tabla 2.5, mediante el cual se realiza la operación de
Shrink.
Endpoint Método Payload esperado
/shrinkDB POST {
"minDate": "2018-10-17T16:37:53",
"maxDate": "2018-10-18T00:00:00"
}
Tabla 2.5: endpoint desarrollado para realizar operaciones de shrink.
El administrador del sistema define una fecha mínima y una fecha máxima. El formato de las
fechas debe ser yyyy-MM-ddThh:mm:ss. El backend va a recuperar todos los documentos que estén
entre esas fechas. Si el nivel de detalle no se quiere por segundo sino por hora, un ejemplo de shrink
podría ser el que se muestra en la figura 2.12, donde se haría un agrupamiento de todos los documentos
entre 4pm y 5pm. Cabe recalcar que la consulta hace un agrupamiento de los datos por IP, lo cual
quiere decir que los documentos que se agrupan pertenecen a la misma máquina física, para no perder
la información individual y por salas con el shrink. En la política de shrink se hace un promedio de
todos los documentos entre dichas fechas, para todos los campos. Los reportes quedan almacenados
en la colección de reportes y los documentos nunca se borran de manera automática.
Cuando el administrador del sistema considere prudente, puede llamar al endpoint
/deleteInDb, que recibe también una fecha mínima y máxima en el mismo formato que el endpoint
del shrink. Este endpoint borrará todos los documentos existentes entre esas fechas.
Figura 2.12: ejemplo de fechas para un shrink por hora.
Figura 2.13: Consulta a la base de datos y política de shrink.
2.3. MongoDB
MongoDB es una base de datos orientada a documentos bajo el modelo NoSQL. Se escogió
esta implementación de base de datos porque el manejo de formato JSON facilita la inserción de los
datos sin procesamiento adicional y porque la carencia de un esquema fijo permite manipular,
cambiar y añadir nuevos campos a medida que se descubre la necesidad específica de métricas de
UnaCloud.
La instancia de MongoDB que sirve de base de datos para el Performance Collector Backend
está desplegada en una máquina física disponible en el laboratorio de redes de la Universidad de los
Andes con dirección IP 157.253.205.96, y sirve en el puerto 27017. El nombre de la base de datos es
performance_collector_unacloud. A continuación se describe el Sistema operativo y características de
hardware de este computador, denominado “Server17”.
○ Sistema Operativo: Ubuntu V16.04 ○ Disco Duro: 512 GB ○ Memoria RAM: 16GB
La versión de mongo instalada es la 4.0.
2.4. ElasticSearch y Kibana
ElasticSearch es un motor de DB distribuido, RESTful, basado en JSON, muy escalable y
optimizado para búsquedas sobre series de tiempo. Kibana es una herramienta de monitoreo y
visualización a la medida, que permite visualizar y validar reglas sobre la DB en tiempo real. Estas
fueron las herramientas elegidas para generar los dashboards de monitoreo sobre el ambiente de
UnaCloud.
Las instancias de ElasticSearch y Kibana que sirven de base de datos secundaria y herramienta
de visualización para el Performance Collector Backend fueron desplegadas en una máquina física
disponible en el laboratorio de redes de la Universidad de los Andes con dirección IP 157.253.205.39 y
sirven en los puertos 9200 y 5601 respectivamente. A continuación se describe el Sistema operativo y
características de hardware del computador denominado “Server23”:
○ Sistema Operativo: Ubuntu V16.04 ○ Disco Duro: 512 GB ○ Memoria RAM: 16GB
Los datos que se almacenan en ElasticSearch son segmentos de métricas del objeto original
que envía el agente de monitoreo. Estos segmentos de métricas fueron definidos de acuerdo a las
necesidades de visualización en los dashboards de Kibana. Cada segmento se guarda en un índice
específico de ElasticSearch. El mapping de un documento define qué campos tiene y de qué tipo son.
En Elastic y Kibana es importante definir bien la estructura del documento, pues una vez creado el
índice, no se puede modificar. Los mappings son guías que le permiten a Kibana, sobre todo, que
formato de fecha se está utilizando. Se consideró que para el monitoreo de métricas eran necesarios 4
índices, que se explican en las figuras 2.14 a 2.17.
El mapping de summary es el principal, pues por cada reporte de un agente se recuperan los
datos más dicientes sobre la máquina para ser visualizados en los dashboards. Este mapping contiene
información sobre promedio de cpu, disco, disco de UnaCloud, RAM y swap. Asimismo, tiene la
cantidad de máquinas virtuales en la máquina física y cuántas de esas imagenes estan corriendo. Posee
también el estado del agente de UnaCloud y el agente del hipervisor Virtualbox. El timestamp que se
definió tiene año, mes, día, hora, minuto y segundo.
Figura 2.14: Mapping del índice de resumen. Contiene métricas más relevantes de las máquinas.
El mapping de CPU contiene el resumen detallado por CPU de cada reporte de los agentes.
Esto con el fin de crear dashboards con información de CPU y distinguir, entre otras cosas, el
porcentaje de consumo del usuario versus el porcentaje de consumo del sistema operativo en las salas.
Este mapping contiene información sobre promedio de cpu, usuario, sistema, idle, interrupciones y
dcp. El timestamp que se definió tiene año, mes, día, hora, minuto y segundo.
Figura 2.15: Mapping del índice con métricas detalladas sólo CPU
El mapping de Memory contiene el resumen detallado por memoria RAM de cada reporte de
los agentes. Esto con el fin de crear dashboards con información de memoria y distinguir entre el
espacio disponible en GB y el porcentaje de uso en las salas. Este mapping contiene información sobre
promedio de ram, memoria usada, disponible y libre. El timestamp que se definió tiene año, mes, día,
hora, minuto y segundo.
Figura 2.16: Mapping del índice con métricas detalladas sólo memoria RAM
El mapping de risk es muy útil, pues cada vez que el sistema detecta una máquina en riesgo
añade un nuevo documento a este índice. Esto permite visualizar qué máquinas físicas necesitan
atención particular.. Este mapping contiene información sobre promedio de cpu, disco, disco de
UnaCloud, RAM y swap. Asimismo, tiene la cantidad de máquinas virtuales en la máquina física y
cuántas de esas imagenes estan corriendo. Posee también el estado del agente de UnaCloud y el agente
del hipervisor Virtualbox. El timestamp que se definió tiene año, mes, día, hora, minuto y segundo.
Figura 2.17: Mapping del índice con métricas de las máquinas en riesgo
En la figura 2.16 se puede apreciar el estado de los índices creados, el número de documentos
que han sido guardados y el tamaño en disco que ocupa cada uno. El health es amarillo porque no hay
réplicas activas y por consiguiente no hay política de tolerancia a fallos para la implementación hecha.
Figura 2.16: Estado de los índices de ElasticSearch después de 3 semanas de recolección de datos.
3. Resultados
3.1. Comparación entre agente antiguo y nuevo agente
El agente desarrollado resultó ser una mejora drástica sobre el anterior. Solo teniendo en
cuenta las herramientas utilizadas se puede ver que ya no es necesario utilizar Perfmon, Sigar, ni Open
Hardware Monitor. Sobre la primera versión del agente se realizaron pruebas de desempeño, cuyos
resultados se pueden observar en las gráficas 3.1, 3.2, 3.3 y 3.4.
Figura 3.1: gráfica de consumo de CPU a través del tiempo, de la versión 1 del nuevo agente desarrollado,
ejecutado por 5 minutos a diferentes frecuencias.
Figura 3.2: gráfica de consumo promedio de CPU de la versión 1 del nuevo agente desarrollado, ejecutado por 5
minutos a diferentes frecuencias.
Figura 3.3: gráfica de consumo de memoria a través del tiempo, de la versión 1 del nuevo agente desarrollado,
ejecutado por 5 minutos a diferentes frecuencias.
Figura 3.4: gráfica de consumo promedio de memoria de la versión 1 del nuevo agente desarrollado, ejecutado
por 5 minutos a diferentes frecuencias.
Cabe resaltar para las gráficas 3.3 y 3.4 que el incremento en el consumo de memoria resultó
ser debido al almacenamiento de los datos que estaban siendo recolectados para medir el desempeño
del agente, y no por la ejecución normal del agente.
Como se puede ver, el consumo promedio en el caso más exigente está alrededor del 5% de
CPU y 0.3% de memoria. Esto se puede contrastar con ejecuciones bajo las mismas condiciones de las
dos herramientas más pesadas que usaba el agente anterior, Sigar y Perfmon, cuyos resultados se ven el
las figuras 3.5, 3.6 y 3.7, donde únicamente entre esas dos herramientas consumen un promedio de
8.5% de CPU.
Figura 3.5: gráfica de consumo de CPU a través del tiempo de Perfmon, ejecutado por 5 minutos
.Figura 3.6: gráfica de consumo de CPU a través del tiempo de Sigar, ejecutado por 5 minutos
Figura 3.7: gráfica de consumo promedio de CPU de Sigar y Perfmon, ejecutados por 5 minutos
Sobre la última versión del agente se volvieron a realizar las mediciones de desempeño, dado
que esta versión es mucho más compleja que la primera. Los resultados de estas mediciones están
disponibles en las figuras 3.8, 3.9, 3.10 y 3.11
Figura 3.8: gráfica de consumo de CPU a través del tiempo de la versión 4 del agente, ejecutados por 1 minuto a
diferentes frecuencias
Figura 3.9: gráfica de consumo promedio de CPU de la versión 4 del agente, ejecutados por 1 minuto a diferentes
frecuencias
Figura 3.10: gráfica de consumo de memoria a través del tiempo de la versión 4 del agente, ejecutados por 1
minuto a diferentes frecuencias
Figura 3.11: gráfica de consumo promedio de memoria de la versión 4 del agente, ejecutados por 1 minuto a
diferentes frecuencias
Finalmente se puede ver que la última versión del agente es mucho más pesada que la primera
versión. Las pruebas reportan que consume alrededor de un 16% de CPU y 0.4% de memoria cuando se
ejecuta enviando mensajes cada segundo. Es necesario resaltar que estas pruebas (tanto las de el nuevo
agente desarrollado como de las herramientas antiguas) se realizaron en un computador portátil con
especificaciones diferentes a las de los computadores de la sala, por lo cual es probable que el consumo
real sea valores mucho menores a los reportados aquí. No obstante, los datos sirven para darnos una
idea de las mejoras que se dieron en cuanto a consumo de recursos por parte del agente de monitoreo,
comparando el anterior con la nueva implementación.
3.2. Dashboards
Se construyeron 6 dashboards y más de 20 visualizaciones. Cada uno de los dashboard tiene
como objetivo reflejar el estado de UnaCloud en tiempo real mientras satisface un requerimiento
específico. Los dashboards, como se explicó anteriormente, están desarrollados sobre la plataforma
Kibana, que recupera las métricas detalladas de los índices de ElasticSearch. La ventaja de haber
utilizado kibana es la facilidad con la cual nuevas métricas, visualizaciones y dashboards pueden ser
generados, sin que implique un gasto de tiempo considerable.
Una de las mayores ventajas es la existencia de filtros, tanto por visualización como por
dashboard. Cada uno de los dashboards creados tiene filtros que permiten discriminar por sala y por
IP (Waira 1, Waira 2 y Turing). Esto permite ver el comportamiento de UnaCloud por sala de
cómputo. Adicionalmente, hay filtros que permiten ver cuando una métrica sobrepasa un límite de
riesgo o cuando el estado del agente de UnaCloud no está disponible.
Dashboard Tabla de información general. Este dashboard presenta todas las métricas que han
sido reportadas en un intervalo de tiempo con sus campos más relevantes. Este dashboard está
compuesto por una sola visualización. Permite ordenar los campos y revisar qué IPs están reportando
el consumo más alto de CPU, RAM, disco y disco dedicado. Entre otras cosas, permite visualizar todas
las máquinas cuyo estado de agente de UnaCloud o VirtualBox no es disponible y sus métricas
respectivas. Este dashboard es una herramienta para entender qué datos están siendo reportados y
revisar por IP específica el contenido neto de su estado en un momento de tiempo determinado.
Figura 3.12: Dashboard tabla de información general.
Dashboard Consumo de Recursos. Este dashboard presenta por cada recurso (CPU, RAM,
swap y disco de UnaCloud) el porcentaje de máquinas que han reportado consumo entre 0% y 20%
(verde), entre 20% y 60% (amarillo) y entre 60% y 100% (rojo). Este dashboard es una herramienta
para entender el consumo general de recursos de hardware y en qué proporción de máquinas físicas
tienen riesgo asociado, dado dichos recurso.
Figura 3.13: Dashboard Consumo de recursos
Dashboard Métricas de performance. Este dashboard presenta todas las métricas que han sido
reportadas en un intervalo de tiempo con sus campos más relevantes, mostrada en forma de gráfica de
línea. Esta forma de visualizar los datos es en particular útil para ver las tendencias de
comportamiento a una hora específica de la semana a lo largo del tiempo, y revisar correlaciones entre
métricas. Este dashboard es una herramienta para entender cómo se comporta una misma métrica a
través del tiempo y como su consumo puede influir directamente en el performance de la máquina en
un momento de tiempo determinado.
Figura 3.14: Dashboard Métricas de performance sin filtro
Figura 3.15: Dashboard Métricas de performance. Sólo datos cuyo porcentaje de CPU sea mayor a 50% y el
estado de UnaCloud sea no disponible
De la figura 3.14 y 3.15 se puede concluir, por ejemplo, que un incremento en CPU está
relacionado con el incremento de consumo de RAM y Swap.
Figura 3.16: Dashboard Métricas de performance.
Dashboard Máquinas reportando. Este dashboard muestra cuántos de los agentes de
monitoreo están reportando métricas de máquinas físicas. Si todos los computadores que prestan
recursos a UnaCloud tienen un agente de monitoreo, la cuenta total debe ser 128 máquinas por unidad
de tiempo. Adicionalmente, se muestra la cuenta de máquinas que están reportando y que además
tienen el agente de UnaCloud con estatus activo. Además, muestra la IP de dichas máquinas, para
saber cuales carecen de un agente de monitoreo reportando y en qué sala. Este dashboard es en
particular importante a la hora de identificar la disponibilidad de máquinas en las diferentes salas,
pues en teoría todas deben tener el agente de UnaCloud activo.
Figura 3.17: Dashboard Máquinas reportando
Dashboard Máquinas en riesgo. Este dashboard recopila todas las métricas sobre máquinas
que el servidor principal Performance Collector Backend determinó que estaban en riesgo. Presenta
todas las métricas reportadas en un intervalo de tiempo, con sus campos más relevantes. Este
dashboard es una herramienta que permite, de forma rápida, identificar qué máquinas físicas
requieren atención inmediata.
Figura 3.18: Dashboard máquinas en riesgo
Dashboard Monitoreo de servidores. Este dashboard reporta las métricas de performance del
Performance Collector Backend server 13, MongoDB server 17 y ElasticSearch /kibana server 23. Esto
se hizo con el fin de monitorear activamente la arquitectura propuesta en este proyecto de grado. Este
dashboard es de especial utilidad para verificar que la carga que están recibiendo los servidores no sea
excesiva para su arquitectura física y para asegurar que queda suficiente espacio en disco disponible
para las bases de datos.
Figura 3.19: Dashboard Monitoreo de servidores
3.3. Alertas y reglas de lógica difusa
El sistema de alertas, que se nutre del modelo de reglas de lógica difusa, ha mostrado ser capaz
de reportar de manera continua todas aquellas máquinas que sufrieron algún fallo y, además,
notificar cuando el daño fue reparado. Con este módulo funcional, el administrador de UnaCloud
está en capacidad de reaccionar en tiempo real ante un problema con cualquiera de las máquinas
físicas.
Figura 3.20: Sistema de notificación vía Email
4. Discusión
En este capítulo se analizan los resultados recién expuestos en el anterior. Esto seguido del
posible trabajo futuro que podría mejorar aún más la precisión de las gráficas resultantes y aminorar
los tiempos de la segmentación. Finalmente, se darán las conclusiones de este proyecto que dan
respuesta a los objetivos planteados en un principio.
4.1. Discusión de resultados
El primer aspecto de los resultados a considerar es el agente de monitoreo desarrollado. Al
compararlo con el agente anterior, que no estaba siendo utilizado a la hora de comenzar este proyecto,
se puede ver que ofrece mejoras considerables. En primer lugar, gracias a la nueva implementación fue
posible eliminar completamente tres de las cuatro herramientas externas que se utilizaban
previamente. Con la adición de la información sobre consumo de energía, no queda ningún dato que
el agente antiguo sea capaz de reportar y que el nuevo no, mientras que lo contrario sí se cumple; RTT
y tiempo offline de una máquina, por mencionar unos ejemplos. Además, fueron solucionados todos
los problemas del agente anterior, tales como consumo excesivo de disco por logs y unificación de
timestamps por métrica.
Segundo, a través de los seis dashboards desarrollados es posible visualizar, analizar y entender
casi todos los componentes que influyen en la correcta ejecución y despliegue de máquinas virtuales
en el ambiente UnaCloud. Estos dashboards fueron creados con el propósito de caracterizar el estado
normal del sistema e identificar patrones que puedan, en un futuro, construir SLAs que prometan
tiempos de disponibilidad, seguridad y confianza al usuario final. Esto, junto con las alertas que
fueron implementadas, dan acceso inmediato a información sobre eventualidades que puedan ocurrir
en UnaCloud.
4.2. Trabajo futuro
Sobre UnaCloud queda mucho trabajo por realizar. Existen múltiples otras oportunidades de
mejora sobre el sistema y también múltiples proyectos que están actualmente en desarrollo. Con el
sistema de monitoreo implementado, tanto estudiantes como profesores podrán aprovechar toda la
información recolectada y analizada. Se tendrá acceso a dashboards y a una gran cantidad de datos
mediante los cuales será posible caracterizar en un momento específico el comportamiento de
UnaCloud. Cabe resaltar que se recolectan muchas métricas que no fueron tenidas en cuenta en el
alcance de este proyecto y que pueden ser aprovechadas en un futuro. Un ejemplo es la recolección de
métricas de energía.
Adicionalmente, el sistema de monitoreo desarrollado no aplica exclusivamente para el
escenario de UnaCloud. Si bien habría que hacer unos cuantos ajustes tanto al código del agente como
al código del Performance Collector Backend, esto podría ser aplicado y utilizado en cualquier otro
sistema distribuido donde se deban monitorear múltiples máquinas físicas.
4.3. Conclusiones
Este proyecto de grado se enmarca en el contexto de implementar desde cero un sistema de
monitoreo robusto para la plataforma UnaCloud, siendo desarrollada por la Universidad de los Andes
sobre máquinas que se encuentran en los laboratorios de sistemas de ésta misma.
En el primer capítulo se discutieron alternativas de sistemas de monitoreo que existen
actualmente y de objetivos que se pueden lograr cuando el monitoreo se lleva a cabo correctamente.
Desafortunadamente, estos servicios en muchas ocasiones resultan ser costosos y no siempre se tienen
los fondos necesarios para costear un servicio de más de $100.00 dólares al mes, así sea muy necesario.
El sistema de monitoreo descrito en este proyecto de grado resulta ser una alternativa
excelente, que se acopla a las necesidades del sistema específico que se desea monitorear en este caso,
UnaCloud, y que queda disponible para su uso y posible extensión en un futuro. Al grupo de
investigación encargado de continuar con el desarrollo de UnaCloud se le hará entrega de todos los
desarrollos enmarcados en este proyecto, junto con un manual para facilitar su uso y posibles futuras
mejoras, esperando que sea de gran ayuda en trabajos por venir.
Los objetivos propuestos se cumplieron en su totalidad. Se desarrolló el sistema de monitoreo
deseado, con una arquitectura final bastante similar a la propuesta inicialmente. En el primer capítulo
del documento se establecieron cuatro objetivos específicos, los cuales serán recapitulados ahora en el
mismo orden.
1. Cada máquina física de UnaCloud está en la capacidad de reportar datos con frecuencia
máxima de una vez por segundo. En casos de fallas de red, el computador es capaz de reportar
que estuvo desconectado por un periodo de tiempo.
2. Se implementó un pipeline capaz de recibir los datos y procesarlos. Estos datos son
presentados en no solo uno, sino múltiples dashboards intuitivos y bien documentados, con
distintos posibles filtros para reducir las visualizaciones a una sala específica, o incluso a una
máquina específica.
3. Se definieron políticas de errores sobre el ambiente de UnaCloud. Esto no solo permite poder
notificar en tiempo real cualquier comportamiento anormal o riesgoso para el sistema, deja
caracterizado el ambiente de UnaCloud y sus fallas. Esto es fundamental para entender como
seguir mejorando el proyecto en el futuro.
4. A partir del análisis realizado, se pudo desarrollar un modelo de estimación de riesgo asociado
a una máquina física a partir de sus métricas de performance. Esto permite realizar
asignaciones de máquinas virtuales a máquinas físicas de manera mucho más inteligente y con
conocimiento del estado y de las capacidades del ambiente y de cada computador en particular.
Dicho lo anterior, se puede afirmar que el proyecto cumplió con los objetivos propuestos, pues
UnaCloud cuenta ahora con un sistema robusto de monitoreo, análisis y alertas, que proveen
herramientas clave a la hora de ofrecer un mejor servicio.
5. Bibliografía
1. Cloud Computing en AWS. Recuperado de
https://aws.amazon.com/es/what-is-cloud-computing/
2. Arquitectura UnaCloud. Recuperado de https://sistemasproyectos.uniandes.edu.co/iniciativas/unacloud/es/arquitectura/
3. Amazon CloudWatch, recuperado de https://aws.amazon.com/cloudwatch/
4. StackDriver Monitoring, recuperado de https://cloud.google.com/monitoring/
5. Gómez, C. (Próximo a publicar). Fault characterization and mitigation strategies in desktop cloud systems. Bogotá, Colombia: Universidad de los Andes.
6. Casos de éxito de UnaCloud. Recuperado de https://sistemasproyectos.uniandes.edu.co/iniciativas/unacloud/es/casos-de-exito/
7. Psutil, recuperado de https://psutil.readthedocs.io/en/latest/
8. ElasticSearch. Recuperado de https://www.elastic.co/products/elasticsearch
9. Kibana, recuperado de https://www.elastic.co/products/kibana
10. Logstash, recuperado de https://www.elastic.co/products/logstash
11. PowerGadget, recuperado de https://software.intel.com/en-us/articles/intel-power-gadget-20
12. Sarmiento, A. (2012). Perfilamiento de fallas en salas de cómputo del departamento de ingeniería de sistemas y computación. Bogotá, Colombia: Universidad de los Andes.
13. Ewaschuk, R. (n.d.). Monitoring Distributed Systems. Recuperado de https://landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems/