# Sprint 2 # 1. INFORME EJECUTIVO DE AVANCES ## 1.1. RESUMEN DE HISTORIAS DE USUARIO Hemos completado la implementación de las Historias de Usuario correspondientes al Sprint 2, lo que nos lleva a que efectivamente nuestro producto está desarrollado en un 50%, partiendo del siguiente esquema nos guía en la implementación del sistema: ![](https://i.imgur.com/Jtc5lPO.png) Al concluir las HU de este Sprint, hemos desarrollado la fase de *Data Preprocessing*, una de las más fundamentales en nuestro proyecto. Lo anterior se puede verificar en las siguientes imagenes que corresponden con las salidas de nuestro LogParser y el Feature Extractor: *Log Parsing* ![](https://i.imgur.com/huNquKT.png) *Feature Extractor* ![](https://i.imgur.com/OjTjfvP.png) ## 1.2. RETROSPECTIVA Y GESTIÓN DE RIESGOS DEL PROYECTO Inicialmente, se nos presentó una dificultad con los Datasets que debíamos usar en el proyecto, pues no teníamos claro cuál podríamos utilizar y la comunicación con el Product Owner estaba un poco complicada. Finalmente, logramos solucionar el problema de las reuniones, y el PO nos aprobó el uso de un Dataset que habíamos encontrado en unos papers que estábamos estudiando. En el momento solo se nos presenta una dificultad que no afecta demasiado el desarrollo del proyecto, se trata de que no tenemos en el grupo los créditos necesarios para el despliegue del sistema en producción, en nuestro caso, no disponemos de los créditos en AWS. Actualmente estamos hablando con la profesora Elizabeth para solventar la dificultad. Por otro lado, llenamos el formulario pidiendo espacio en el DCA y todavía no recibimos respuesta. Las diapositivas de DevOps y Arquitectura intensiva en datos no se encuentran en ningún link compartido con el grupo. Ya enviamos un correo al respecto. # 2. URL DE LOS AMBIENTES DEVOPS ## 2.1. REPOSITORIO EN GIT (DEV) https://github.com/cgavir29/S3YN ## 2.2. APLICACIÓN EN PRUEBAS (TESTING) El entorno de pruebas aplica para nuestro proyecto y será implementado en el DCA de la universidad para el entrenamiento del modelo propuesto. Ya se estableció una solicitud de recursos para la configuración de éste, lastimosamente, debido a los inconvenientes presentados con la charla propuesta este proceso no se pudo hacer con anterioridad. ## 2.3. APLICACIÓN EN PRODUCCIÓN (RELEASE) En el sprint anterior la aplicación había sido desplegada en AWS utilizando recursos de otro curso, dichos recursos ya se han agotado, es por ello que estamos a la espera de ser agregados al nuevo grupo de este curso (Proyecto Integrador 2) para proceder con el despliegue una vez más. # 3. ARQUITECTURA BASE ## 3.1. GESTIÓN DE LA CONFIGURACIÓN Y AMBIENTE V2 Ver Azure. ## 3.2. DEFINICIÓN DE ARQUITECTURA V2 ### 3.2.1. INTEGRACIÓN ENTRE SISTEMAS ![](https://i.imgur.com/ZT8wvjm.png) El sistema se integra con dos entidades: - **Data Analyst User:** Es el usuario que hace uso de nuestros servicios por medio de la aplicación web, este podrá monitorear el estado del sistema en cualquier momento. - **Customer IoT Platform:** Este servicio de nube en la que el cliente tiene desplegada su plataforma de IoT. Esta plataforma es la fuente de datos para realizar los análisis de las anomalías que se presenten en el sistema. ### 3.2.2. VISTA FUNCIONAL ![](https://i.imgur.com/pxoYrsz.png) | **Nombre del Sistema, Subsistema, Entidad o Componente** | **Descripción** | **Interacción** | |--|--|--| | Register | Es la interfaz del usuario para crear un usuario. | Interactúa con el componente de autenticación para validar los datos de registro. | | Login | Es la interfaz del usuario para ingresar a la aplicación con un usuario existente. | Interactúa con el componente de autenticación para validar los datos de un usuario existente. | | Visualization | De manera gráfica se muestra al usuario lo que está pasando en el sistema referente a las anomalías que se presentan. | Recibe los datos del componente de detección de anomalias para mostrar los resultados al usuario en su interfaz. | | IoT Customer Platform | Es la fuente de los datos a analizar (logs). | Debe comunicar los datos con el componente de preparación y limpieza. | | Preparation and data cleaning | Aquí se procesan los datos para que se pueda aplicar el análisis de forma más precisa. | Se comunica con el almacenamiento interno para guardar ciertas configuraciones. | | Internal storage | Es la base de los datos de nuestro sistema. | Provee datos a los demas sistemas. | | Anomaly detection | Es el componente donde se realiza el análisis de datos y por medio de Machine Learning se detectan fallas en los QoS del cliente. | Reporta resultados al componente de visualización. | |Log_parser|Es el encargado de implementar el algoritmo de LogParser.| Recibe los datos del componente de preparación y limpieza y entrega el resultado al componente de extracción de características.| |Feature_extraction|Es el encargado de ejecutar el algoritmo para la extracción de características.| Recibe los datos del componente log_parser y entrega el resultado al componente de detección de anomalías.| |Autentication|Valida los datos que sean recibidos. |Interactúa con el componente de registro y login recibiendo datos de ellos.| ### 3.2.3. VISTA DE INFORMACIÓN / MODELO DE DATOS Optamos por una base de datos NoSQL (MongoDB) para almacenar los resultados de las diferentes etapas de nuestra solución de detección de anomalías. Esta decisión se tomó debido a que los datos que se generan no tienen una estructura definida ya que dependen de los _**logs**_ que el sean proveídos por el usuario. Estos datos generados son los eventos, características y anomalías que se detectan en base a la información proporcionada, además, estos datos pueden variar considerablemente dependiendo del tipo de dispositivo de IoT que generó dichos logs. Tomando como referencia el ejemplo de [modelo de datos de MongoDB](https://docs.mongodb.com/manual/core/data-model-design/) se presenta la siguiente estructura. Un documento **User** donde se almacenan la información necesaria para acceder a la plataforma y un documento **Result** que está relacionado con un usuario y que almacena todos los eventos, características y anomalías que se detectaron para un _log_ determinado, a este resultado se le puede asignar un nombre para fácil diferenciación. ![](https://i.imgur.com/jmhJYdP.png) El flujo de los datos es el siguiente: 1. Usuario sube un log a la plataforma desde su dispositivo o ingresa un link a un almacenamiento externo (AWS S3) para obtener el log. 2. Una vez subido el fichero se activa el programa de 'Log Parsing'. 3. El Sistema extrae cada uno de los eventos que sucedieron en los logs analizados. 4. Una vez obtenido los eventos que ocurrieron se activa el programa de 'Feature Extraction'. 5. El Sistema extrae las características que ocurrieron en los eventos analizados. 6. El Usuario decide si desea guardar los eventos y las características entregadas o si desea activar el programa una vez más. ### 3.2.4. VISTA DE DESPLIEGUE ![](https://i.imgur.com/Xt9K7uy.png) Se tienen tres grandes bloques en nuestra aplicación los cuales están desplegados en AWS con sistema operativo Ubuntu 18.04 a excepción de la base de datos manejada que corre sobre Linux AMI 2. 1. **Frontend:** Recibe todas las peticiones que el usuario haga a través del navegador y envía respuestas en forma de vistas de regreso. La información es dinámica, es decir, cambia dependiendo del usuario que esté utilizando la apliación, toda esta información se extrae del backend por medio de servicios REST. 2. **Backend:** Es donde se desarrolla la detección de anomalías así como la autenticación de usuarios en la plataforma y los esquemas de lectura a la base de datos NoSQL (MongoDB). Expone REST API endpoints para ser consumidos por el frontend cuando se solicita cierto servicio. 3. **Database:** Base de datos MongoDB, que se utiliza para almacenar el registro de usuario como los resultados de los modelos de detección de anomalías que el usuario ha desarrollado. ### 3.2.5. VISTA DE DESARROLLO ![](https://i.imgur.com/r857Zck.png) ### 3.2.6. ATRIBUTOS DE CALIDAD DEL SISTEMA #### 3.2.6.1. RENDIMIENTO Y ESCALABILIDAD | **Requirement** | **How Met** | |--|--| | El promedio de tiempo de respuesta de la página web a los usuarios debe ser de 5 seg o menos | El sistema contará con una infraestructura en AWS permite manejar un gran nivel de concurrencia debido a la robustez de la tecnología. | #### 3.2.6.2. SEGURIDAD | **Requirement** | **How Met** | |--|--| | Todos los usuarios deben de ser autenticados | Se tendrá un login el cual solo se podrá autenticar los usuarios que estén registrados. | | Los datos utilizados deben estar protegidos | La base de datos a utilizar estará en la nube, y este nos permite: no tener acceso público y tener todos los datos encriptados. | #### 3.2.6.3. DISPONIBILIDAD Y RESILIENCIA | **Requirement** | **How Met** | |--|--| | Los datos deben de estar siempre disponibles. | El sistema de nube en el que se va a montar nos da este servicio para manejar failover y tener un cluster de los datos. | | El sistema debe soportar aproximadamente 100 personas a la vez. | El sistema contará con un balanceador de carga y estará en AutoScalingGroup el cual permitirá tener más instancias que se harán cargo de los usuarios que sean necesarios. | #### 3.2.6.4. EXTENSIBILIDAD | **Requirement** | **How Met** | |--|--| | El sistema debe poner soportar la integración de otras funcionalidades. | El sistema estará diseñado de tal forma que es posible añadir cualquier tipo de nueva funcionalidad como por ejemplo la detección de anomalías online. | #### 3.2.6.5. OTROS ATRIBUTOS DE CALIDAD #### 3.2.6.5.1 Usabilidad | **Requirement** | **How Met** | |--|--| | El sistema debe ser intuitivo. | El sistema tendrá un diseño agradable con el usuario lo cual hará que sea fácil de manejar. | |El sistema debe permitir almacenar ficheros grandes en términos de almacenamiento. | El sistema contará con una arquitectura que permitirá de lado de la persistencia escalar en terminos de almacenamiento, asegurando que ficheros de grandes volumenes puedan ser almacenados. | ## 3.3. ESTADO DEL ARTE, VIGILANCIA TECNOLÓGICA Y SELECCIÓN DE LA TECNOLOGÍA V2 ### 3.3.1. Estado del arte #### 3.3.1.1. Análisis de Datos: El Análisis de Datos es la ciencia que examina datos en bruto con el propósito de sacar conclusiones sobre la información. El análisis de datos se centra en la inferencia, el proceso de derivar una conclusión basándose solamente en lo que conoce el investigador. (Rouse, 2012). #### 3.3.1.2. Internet of Things: La proliferación de objectos conectados ha revolucionado el internet tracional, dando lugar al emergente internet de las cosas (IoT). El ecosistema IoT es bastante grande, y este incluye interconexiones inteligentes entre los sensores y los dispositivos mediante aplicaciones, tanto en el mundo industrial como en el día a día de los clientes. (Elhammouti, Sabir, Benjillali, Echabbi & Tembine, 2017). #### 3.3.1.3. Detección de Anomalías: Detectar anomalías en redes de datos consiste en la identificación de patrones que se desvían del comportamiento normal de de los datos, por lo que está íntimamente relacionado con el modelado de los datos. (Barrionuevo, Lopresti, Miranda & Píccoli, 2016). #### 3.3.1.4. Metodología MIDANO: Midano es una metodología para el desarrollo de aplicaciones de minería de datos basadas en el análisis organizacional. Esta metodología está dividida en 3 fases que son las siguientes: ##### Fase 1: Conocimiento de la Organización ![](https://i.imgur.com/acMuANz.png) En esta fase se tiene como finalidad realizar un proceso de ingeniería de conocimiento, orientado a organizaciones/empresas, de las cuales no se conoce o se tiene poca información del (de los) problema(s), o los procesos a estudiar. ##### Fase 2: Preparación de los Datos ![](https://i.imgur.com/9HdeWQr.png) En esta fase se plantea realizar la preparación de los datos desarrollando dos etapas. Los productos más resaltantes de esta fase son las vistas minables (conceptual y operativa) y las variables objetivos. ##### Fase 3: Desarrollo de herramientas de MD ![](https://i.imgur.com/zUtlnk8.png) (Aguilar, s.f.) #### 3.3.1.5. Data Mining: La minería de datos es el descubrimiento de interesantes, inesperadas o valiosas estructuras en grandes datasets (Hand, 2007). En cuanto a la minería de datos nos encontramos con una metodología llamada CRISP-DM (Cross-Industry Standard Process for Data Mining) la cual consta de las siguientes fases: ![](https://i.imgur.com/KzvHHgA.png) #### 3.3.1.6. Metodología CRISP-DM ##### Comprensión del Negocio: - Determinar los objetivos del negocio - Valoración de la situación - Determinar los objetivos de DM - Realizar el plan del proyecto ##### Comprensión de los Datos: - Recolección de los datos iniciales - Descripción de los datos - Exploración de los datos - Verificar la calidad de los datos ##### Preparación de los Datos: - Seleccionar los datos - Limpieza de los datos - Estructurar los datos - Integrar los datos - Formateo de los datos ##### Modelado: - Selección de la técnica de modelado - Generar el plan de prueba - Construcción del modelo de DM - Evaluación del modelo ##### Evaluación: - Evaluar los resultados - Revisión del proceso - Determinar los próximos pasos ##### Implementación: - Plan de implementación - Plan de monitoreo y mantención - Informe final - Revisión del proyecto (Wirth & Hipp, 2000) ### 3.3.2. Vigilancia Tecnológica (VT) #### Experience Report: System Log Analysis for Anomaly Detection: Traditionally, developers (or operators) often inspect the logs manually with keyword search and rule matching. The increasing scale and complexity of modern systems, however, make the volume of logs explode, which renders the infeasibility of manual inspection. To reduce manual effort, many anomaly detection methods based on automated log analysis are proposed. However, developers may still have no idea which anomaly detection methods they should adopt, because there is a lack of a review and comparison among these anomaly detection methods. Moreover, even if developers decide to employ an anomaly detection method, re-implementation requires a nontrivial effort. To address these problems, we provide a detailed review and evaluation of six state-of-the-art log-based anomaly detection methods, including three supervised methods and three unsupervised methods, and also release an open-source toolkit allowing ease of reuse. (He, Zhu, He & Lyu, 2016). #### Experimental Comparison of the Diagnostic Capabilities of Classification and Clustering Algorithms for the QoS Management in an Autonomic IoT Platform: The Internet of Things (IoT) platforms must allow the communication between the Applications and Devices according to their non-functional requirements. One of the main non-functional requirements is the Quality of Service (QoS). In a previous work has been defined an autonomic IoT platform for the QoS Management, based on the concept of autonomic cycle of data analysis tasks. In this platform have been defined two autonomic cycles, one based on a classification task that determines the current operational state to define the set of tasks to execute in the communication system to guarantee a given QoS. The other one is based on a clustering task that discovers the current operational state and, based on it, determines the set of tasks to be executed in the communication system. This paper analyzes the diagnostic capabilities of the system based on both approaches, using different metrics. (Morales, Ouedraogo, Aguilar, Chassot & Medjiah, 2019). #### Abstracting Execution Logs to Execution Events for Enterprise Applications: In this paper, we propose using execution logs to monitor the execution of applications. Unfortunately, execution logs are not designed for monitoring purposes. Each occurrence of an execution event results in a different log line, since a log line contains dynamic information which varies for each occurrence of the event. We propose an approach which abstracts log lines to a set of execution events. (Jiang, Hassan, Flora & Hamann, 2008). ### 3.3.3. Justificación de las Tecnologías En base a las reuniones que se tuvieron con el Product Owner y con el profesor Jose Lisandro Aguilar se optó por continuar con el trabajo de la tecnología de los ciclos autónomos basados en la analítica y minería de datos, ya que el profesor Jose la propuso y nuestro Producto Owner estuvo de acuerdo con su implementación en el proyecto. Esta tecnología se relaciona con el estado del arte actual ya que la metodología MIDANO se usa con el fin de realizar un correcto desarrollo del ciclo autónomo, mientras que para la minería de datos podemos usar CRISP-DM que se especializa en los proyectos de minería de datos como es en este caso. Finalmente, apoyándonos en este ciclo autonómo en el Sprint #2 nos enfocamos en completar toda la etapa correspondiente al pre-procesamiento de los datos, que consta de dos grandes fases, la primera, un log parser que se encarga de extraer los eventos que ocurren dentro de cada uno de los logs de un sistema X, y finalmente un extractor de características que se encarga de obtener el vector de características del log analizado. Ambas tecnologías fueron basadas en los papers que se consultaron (Para más información revisar la sección de los entregables específicos por proyecto), además de esto el profesor Jose y nuestro Product Owner aprobaron el uso del log parser, sin embargo, queda pendiente presentarles el extractor de características para su aprobación. # 4. PLATAFORMA AZURE DEVOPS ![](https://i.imgur.com/Sw5o2To.png) ![](https://i.imgur.com/NCO3YFt.png) ![](https://i.imgur.com/vOACyw4.png) # 5. INTEGRACIÓN CONTINUA Creación del producto de manera automática - build utilizando Docker. Se configuró un Dockerfile y un docker-compose.yml ![](https://i.imgur.com/a8hMtp3.png) ![](https://i.imgur.com/df0JPGy.png) Luego se corre el siguiente comando para crear el contenedor: `docker-compose up -d` ![](https://i.imgur.com/XqkVhiI.jpg) ![](https://i.imgur.com/sEGANJ6.jpg) # 6. ENTREGABLES ESPECÍFICOS POR TIPO DE PROYECTO ## 6.1. DATOS DE ENTRENAMIENTO Los datos de entrenamiento que hemos seleccionado para la implementación de nuestro proyecto son los datos de un sistema HDFS en ejecución. Se pueden encontrar aquí: https://github.com/logpai/logparser/tree/master/logs/HDFS. En el mismo directorio se encuentran los datos etiquetados para hacer análisis con modelos de Machine Learning supervisado. Seleccionamos ese dataset porque era común encontrarlo en los papers sobre detección de anomalías, además nuestro Product Owner aprobó el uso de esos datos. ## 6.2. MODELOS EVALUADOS Y MODELO SELECCIONADO Para la etapa de preprocesamiento que hemos implementado, teniamos varias opciones de LogParser implementadas en distintos artículos de investigación. De ese conjunto de posibilidades, logramos abstraer y determinar que habían dos modelos genéricos en todas las soluciones propuestas: 1. Basado en análisis de *Tokens*. 2. Basado en *Clustering* de *Logs*. Seleccionamos el análisis basado en *Tokens* porque evidenciamos en los papers, que eran más efectivos que los demás algoritmos. Específicamente seleccionamos [AEL](http://www.cse.yorku.ca/~zmjiang/publications/jsme2008.pdf). En el caso del extractor de características, no había una cantidad considerable de opciones, finalmente todos los algoritmos entregaban un *vector de características*, en este caso teníamos dos opciones: 1. Vector de características con elementos que reflejan el número de apariciones del evento en el *documento.* 2. Vector de características con elementos que corresponden con el IDF de cada evento. Nuestra implementación en el momento está con el primer enfoque, sin embargo tenemos la duda de cuál es la diferencia en términos de efectividad de los dos enfoques, esa duda será planteada al profesor Jose. ## 6.3. VALIDACIÓN DEL MODELO Validamos nuestro modelo mediante la comparación del número de bloques (*documentos*) que el extractor de características implementado por nosotros daba como resultado, con el número de bloques que se encuentran en los datos etiquetados en los datasets que usamos. Los resultados del análisis fueron los siguientes: - Encontramos **580.406** bloques con nuestro algoritmo. - Los datos verdaderos tienen **575.062** bloques. Se puede evidenciar una diferencia no muy grande, lo que nos lleva a pensar que el algoritmo implementado está funcionando correctamente. ## 6.4. EJECUCIÓN DEL MODELO El código fuente se puede encontrar en: https://github.com/cgavir29/S3YN/tree/master/anomaly_detection. Implementamos el algoritmo con el lenguaje de programación Python. ![](https://i.imgur.com/AcmxOed.png) ![](https://i.imgur.com/rHoE6vL.png) # 7. ESPECIFICACIÓN DE LA TECNOLOGÍA ## 7.1. CLIENTE WEB Y/O MÓVIL Decidimos usar un cliente web debido a que los analistas de datos trabajarán con archivos grandes y tendrán métricas mediante un dashboard, estas funcionalidades son usables desde la web y no es cómodo para el usuario si se usa desde un dispositivo móvil. ## 7.2. INTEGRACIÓN CON REDES SOCIALES **No aplica** debido a que el público objetivo de nuestra solución está orientado a un grupo de personas que trabajan conjuntamente en el seguimiento y monitoreo de sistemas dentro de una organización. Por lo tanto estas personas usarán nuestro sistema con sus cuentas coporativas-educativas. ## 7.3. LENGUAJES DE PROGRAMACIÓN - HTML - CSS - JavaScript - Python 3 ## 7.4. LIMITACIONES Actualmente no tenemos limitaciones, sin embargo, en el transcurso del proyecto se nos presentó una dificultad relacionada con el proveedor de nube para el despligue del sistema, la situación fue solventada con recursos para AWS provistos por los profesores del curso. ## 7.5. PLATAFORMA DE GESTIÓN DE PROYECTOS Para la gestión de los sprints y las correspondientes historias de usuario usamos la plataforma Azure DevOps, para la gestión general del proyecto usamos Asana. ## 7.6. FRAMEWORKS ### 7.6.1. DESARROLLO WEB/MÓVIL CONVENCIONAL - **Bulma:** Estilos de CSS, una alternativa a Bootstrap. - **Buefy:** Blueprint de componentes para Vue. - **Vue:** Para el desarrollo del frontend de la página web. - **Flask:** Micro framework para para el backend que suple las API necesarias. ### 7.6.2. DESARROLLO EN LA TECNOLOGÍA EMERGENTE - **SciKit:** Es una biblioteca de aprendizaje automático para el lenguaje de programación Python 3. ### 7.6.3. TECNOLOGÍA PARA DEVOPS - GitHub. - Jenkins. - Docker. ## 7.7. AMBIENTE DE DESARROLLO, PRUEBAS Y PRODUCCIÓN ### 7.7.1. DESARROLLO (LOCAL) - **Sistema Operativo:** Linux, MacOS o Windows. - **IDE:** Vim y VSCode. - **Servidor App:** Localhost. - **Servidor Base de Datos:** MongoDB Atlas en AWS. - **Archivos:** Local. ### 7.7.2. PRUEBAS (DCA) - **Sistema Operativo:** Linux (CentOS 7). - **IDE:** Vim. - **Servidor App:** Localhost. - **Servidor Base de Datos:** MongoDB Atlas en AWS. - **Archivos:** AWS S3. ### 7.7.3. PRODUCCIÓN (AWS) - **Sistema Operativo:** Linux (Ubuntu 18.04). - **IDE:** Vim. - **Servidor App:** Localhost. - **Servidor Base de Datos:** MongoDB Atlas en AWS. - **Archivos:** AWS S3. ### 7.7.4. TECNOLOGÍAS ESPECÍFICAS - **Docker:** Para el despliegue en AWS. ## 7.8. REQUISITOS DE SISTEMAS EMBEBIDOS E IOT No aplica. ## 7.9. PLATAFORMAS PARA CLOUD COMPUTING No aplica. ## 7.10. BIBLIOTECAS DATA SCIENCE - Scikit. - NumPy. - Matplotlib. ## 7.11. OTRAS TECNOLOGÍAS ESPECÍFICAS - Docker. - NodeJS. # 8. DRAFT DOCUMENTO FINAL https://drive.google.com/open?id=1kL080yLrF7uB-15_WT0LLRQYrSJ0I_MH # 9. BIBLIOGRAFÍA Lin, Q., Zhang, H., Lou, J. G., Zhang, Y., & Chen, X. (2016, May). Log clustering based problem identification for online service systems. In 2016 IEEE/ACM 38th International Conference on Software Engineering Companion (ICSE-C) (pp. 102-111). IEEE. Jiang, Zhen & Hassan, Ahmed E. & Flora, Parminder & Hamann, Gilbert. (2008). Abstracting Execution Logs to Execution Events for Enterprise Applications (Short Paper). Proceedings - International Conference on Quality Software. 181 - 186. 10.1109/QSIC.2008.50. Jiang, Z. M., Hassan, A. E., Hamann, G., & Flora, P. (2008). An automated approach for abstracting execution logs to execution events. Journal of Software Maintenance and Evolution: Research and Practice, 20(4), 249-267. Rouse, M. (2012). ¿Qué es Análisis de datos?. Retrieved 15 February 2020, from https://searchdatacenter.techtarget.com/es/definicion/Analisis-de-Datos Elhammouti, H., Sabir, E., Benjillali, M., Echabbi, L., & Tembine, H. (2017). Self-organized connected objects: Rethinking qos provisioning for iot services. IEEE Communications Magazine, 55(9), 41-47. Barrionuevo, M., Lopresti, M., Miranda, N. C., & Piccoli, M. F. (2016). Un enfoque para la detección de anomalías en el tráfico de red usando imágenes y técnicas de computación de alto desempeño. In XXII Congreso Argentino de Ciencias de la Computación (CACIC 2016). Aguilar, J. MIDANO. Retrieved 15 February 2020, from http://www.ing.ula.ve/~aguilar/actividad-docente/AD/documentos/EjemploMIDANO.pdf Wirth, R., & Hipp, J. (2000, April). CRISP-DM: Towards a standard process model for data mining. In Proceedings of the 4th international conference on the practical applications of knowledge discovery and data mining (pp. 29-39). London, UK: Springer-Verlag. He, S., Zhu, J., He, P., & Lyu, M. R. (2016, October). Experience report: System log analysis for anomaly detection. In 2016 IEEE 27th International Symposium on Software Reliability Engineering (ISSRE) (pp. 207-218). IEEE Morales, L., Ouedraogo, C. A., Aguilar, J., Chassot, C., Medjiah, S., & Drira, K. (2019). Experimental comparison of the diagnostic capabilities of classification and clustering algorithms for the QoS management in an autonomic IoT platform. Service Oriented Computing and Applications, 13(3), 199-219. Jiang, Z. M., Hassan, A. E., Flora, P., & Hamann, G. (2008, August). Abstracting execution logs to execution events for enterprise applications (short paper). In 2008 The Eighth International Conference on Quality Software (pp. 181-186). IEEE.