SIGNA

1. SIGNA

2. SIGNASistema Integral Gestión y Notificación de Alarmas Autores Edgardo Silvera Pablo Larraz Walter Fernández Tutor Enrique Latorres 2009

3. Agenda

4. SIGNA (Sistema Integral de Gestión y Notificación de Alarmas) nace de la necesidad de implementar una solución fiable para el monitoreo en tiempo real, detección de errores, notificación de fallos y posterior seguimiento de costos generados por los problemas identificados. El proyecto Signa contempla entonces: Introducción

5. Amenaza: Tercerización Oportunidades: Mejoras • Se desarrolló para el centro de cómputos del MTOP • (Ministerio de Transporte y Obras Públicas). • El MTOP es una de las instituciones que integran el gabinete del poder ejecutivo de este país. Tiene a su cargo el desarrollo y la planificación de obras públicas de infraestructura con el fin de promover el desarrollo nacional. • Necesidades • Mejorar el control de los servicios (automatizar) • Disminuir tiempos de respuesta • Crecimiento (nuevos servicios) • Personal limitado • Seguimiento de tareas y costos Cliente

6. Fases del proyecto

7. Introducción • Modalidad de trabajo en equipo coordinado • Sitio Web como portal de trabajo conjunto • Utilizando repositorios para el código y los documentos. • Planificación de reuniones semanales de coordinación Metodología http://sites.google.com/site/proyectosigna/

8. Introducción • Contacto con el cliente • mail • teléfono • Comunicacióninterna • MSN • Mail • teléfono • sitio web • Coordinación de reunionesperiódicas (cronograma) La gestión del proyecto tuvo en cuenta los siguientes componentes: • Responsablesporfases • Marcelo: investigación de alternativas de software • Pablo: responsable del sistemaSigna Web • Walter: infraestructura, Pandora, ETL Gestión de Proyecto • Comunicación • Correctaselección de software • Falta de experiencia • Problemas de comunicación • Cliente • Interna • Roles, tareas y división de trabajo • Calendario de entregasinternas • Manejo de riesgos • Manejo de repositorio de versionado (SVN) • Convención de nombreparanombre de archivos. Ejemplo; Proyecto SIGNA [Documento - Actividades de Relevamiento v0.2.09082422].doc • Hitos y entregables • Revisióncruzada de entregables • Manejo de estándares • Versionado • Control de calidad

9. No reinventar la rueda • Costos • Tiempolimitado (6 meses) • Aceptado de riesgos • Consultoría Investigación Alternativas

10. Investigación Identifica tres etapas que se deben seguir para seleccionar de forma exitosa un sistema de monitoreo y notificación: Proceso de Selección

11. Investigación • Es el primer paso • Es crucial para que la selección del software sea exitosa. • Confeccionar una lista de requerimientos o características necesarias que el software debe contemplar: • Requerimientos funcionales • Requerimientos no funcionales Características y requerimientos del sistema

12. • Debe ser un sistema Floss • Se debe poder implementar sobre cualquier sistema operativo. • Debe poder monitorear distintas plataformas. • Debe generar alertas cuando se sobrepasen umbrales definidos. • Debe monitorear hardware y software tales como: aplicaciones, sistemas operativos, bases de datos, servidores web, VPN, procesos, servicios, firewalls, proxies, routers, switches, interfaces de red, etc. • Debe enviar mensajes SMS informando cuando falle algún sistema o aplicación que se considere esencial. • Debe generar informes estadísticos. Investigación Características y requerimientos del sistema a elegir

13. Búsqueda de sistemas disponibles en base a las necesidades planteadas • Fuentes de búsqueda elegidas: • • Búsqueda en Internet • • Consulta a profesionales con conocimientos del dominio • Confección de lista de sistemas candidatos • Se encontraron en primera instancia alrededor 50 sistemas Investigación Lista de Sistemas

14. Investigación • Importancia de utilizar una Metodología • Metodologías existentes • • Open Source Maturity Model (OSMM) desarrollado por Bernard Golden de Navicasoft. • • Open Source Maturity Model (OSMM) desarrollado por CapGemini. • • Business Readiness Rating (BRR) creado por Atos Origin. • • Qualification and Selection of Open Source software (QSOS) creada por Carnegie Mellon West y Intel. • Análisis y comparación entre las metodologías QSOS y BRR Metodología de selección de software

15. Investigación • QSOS y BRR presentan básicamente las mismos pasos: • Criterios de evaluación predefinidos • Puntuar los distintos criterios • La importancia de cada criterio se puede ajustar al contexto • Elección en base a los resultados obtenidos • QSOS y BRR difieren en el orden de los pasos • Difieren en el sistema de puntuación Comparación entre las Metodologías QSOS y BRR QSOS: comparaciónmás universal BRR: se adaptamás a los distintoscontextos

16. Investigación • Al momento de elegir la metodología se prioriza: • Poder contemplar el contexto actual del proyecto. • Poder ponderar con mayor peso criterios propios de este proyecto. • La metodología elegida para realizar la comparación de sistemas es BRR. • Esta se adapta de forma más adecuada a estas característica • Ofrece una metodología estándar adaptable a distintos contextos Selección de la Metodología

17. Metodología: • Identificación de sistemas candidatos • Filtrado de sistemas y elección de los tres o cuatro sistemas finalistas • Aplicación del sistema de puntuación para los sistemas finalistas • Elección del sistema • Etapas adicionales: • Instalación y descripción de los sistemas finalistas. • Pruebas de funcionamiento del sistema elegido Investigación Etapas de la metodología BRR

18. Investigación • Identificar características a evaluar: • Sugeridas por la metodología • Contexto de este proyecto. • Ordenan según su importancia. Algunos de estos son: • Uso objetivo: de la aplicación debe ser para uso regular, se deben descartar aquellas aplicaciones que cuyo objetivo sea para desarrollo o experimentación. • Evaluar el tipo de licencia: el sistema debe ser de código abierto Selección primaria de sistemas candidatos

19. Investigación • El sistema debe monitorear al menos 15 componentes • Debe monitorear: Servidores (uso de memoria, uso de CPU, uso de disco, etc.), aplicaciones (servidores de base de datos, etc.), y dispositivos de red (routers, etc.). • Debe monitorear servidores con sistemas operativos Windows, Linux y Unix. • El servidor se debe poder instalar en Linux. • Debe generar alertas cuando se identifican situaciones que así lo ameriten. • Los datos se deben poder exportar a una base relacional open source. • El sistema debe trabajar con agentes instalados en los equipos clientes. Selección primaria de sistemas candidatos

20. Se encuentran y investigan 48 Sistemas Candidatos • Política de selección: • Consiste en corroborar que todas las características que se identifican como imprescindibles se cumplan de forma obligatoria. • Luego de reducida la lista a aquellos sistemas que cumplan con todas estas características, se tendrán en cuenta aquellas no obligatorias para continuar con el descarte. • Los sistemas que en principio cumplen con todos los requisitos son los siguientes: Investigación Eliminación de sistemas candidatos

21. Investigación • La metodología propone que se comparen los 3 sistemas que mejor se adaptan a las necesidades. • Para realizar la selección de los sistema finalistas se ponderaron algunas características más que otras y estas fueron: • Estabilidad y permanencia en el mercado. • Respuesta de las comunidades ante consultas planteadas a las mismas. • Existencia de premios y reconocimientos. • Existencia de Clientes importantes. Selección de sistemas finalistas

22. Hyperic HQ: Reconocimientos a nivel de premios Es un sistema muy estable y completo. Nagios: Líder indiscutible de mercado en cuanto a reconocimiento Es uno de los sistemas más usados y más conocidos de esta familia Gran cantidad de bibliografía disponible y reconocimiento. Pandora FMS: Tiene una comunidad muy activa que respondió a las consultas del grupo de proyecto en forma muy rápida y cordial. Cuenta con interesantes clientes en el área financiera, industrial y en el área pública española. Investigación Sistemas Finalistas

23. Investigación • Descripción de sistemas finalistas: • Conocimiento de los sistemas • Documentación básica de los mismos • Instalación de sistemas finalistas: • Conocimiento de los sistemas • Diferencias entre sistemas • Pruebas sobre los sistemas • Corroborar funcionamiento de las funcionalidades Instalación y Descripción de los sistemas finalistas

24. Ponderación de Categorías según su importancia otorgada por el equipo de proyecto. • Selección y ponderación de métricas aplicadas en cada Categoría Investigación Selección y ponderación de categorías y métricas

25. La elección de las categorías se justifica por los siguientes criterios: • Funcionalidad: • Es la categoría de mayor peso • Las métricas se puntúan de forma distinta • Calidad: • Responda de buena manera • Asegurando cierto grado de calidad en su accionar • Release, Errores, Tiempos • Usabilidad: • El sistema va a ser usado por personas ajenas al equipo de selección. • Instalación y configuración • Interfaz de usuario • Fácil uso • Claro • Intuitivo Investigación Justificación de selección de categorías

26. Rendimiento: • Rendimiento aceptable del sistema • Responda en tiempos esperados • Métricas • Pruebas e informes de rendimiento • Configuración óptima del sistema • Apoyo: • Calidad y velocidad de apoyo profesional ante problemas • Disposición a ayudar a resolver inconvenientes • Comunidad: • Comunidad activa • Cantidad de contribuyentes de código • Arquitectura: • Flexibilidad para realizar cambios y manejar nuevas funcionalidades • Pluggins, Apis • Prever posibles nuevos requerimientos. Investigación Justificación de selección de categorías

27. Los valores finales obtenidos de los sistemas son los siguientes: Investigación Selección del sistema • Funcionalidad: Los 3 sistemas finalistas lograron el máximo puntaje Calidad: El sistema elegido está con el mejor puntaje. • Pandora cuenta con una puntuación respecto a los errores críticos. • Pandora es el que los soluciona en mayor porcentaje (79%). • Liberación de nuevas versiones es el sistema que mejor se comporta en este rubro.

28. Investigación • Usabilidad: • El sistema elegido cuenta con una interfaz de usuario amigable e intuitiva p • Permite desarrollar las tareas de administración y configuración forma sencilla. • Soporte: • Se obtuvieron respuestas en tiempo y forma en cuanto a inquietudes de funcionamiento e instalación del sistema. • Mejores resultados que los otros sistemas • El mayor puntaje según la metodología BRR en el contexto planteado en este proyecto es Pandora FMS. • Se puede señalar también que Pandora es un sistema que ha sido estable desde su versión 1.0 (año 2004). Selección del sistema

29. Investigación • Luego de seleccionar el sistema Pandora FMS, hay que analizar si todos los requerimientos son contemplados en el sistema. • Pandora cumple con los siguientes requerimientos: • Monitorización de los sistemas del centro de cómputos • Notificación de alarmas • Generación de reportes generales • Requerimientos no cumplidos por el sistema: • Generación de reportes orientados a cuantificar los costos generados por la caída de los distintos sistemas monitoreados. • Tareas realizadas en el centro de cómputos y costos. Adopción del sistema

30. Investigación • Posibles soluciones: • La primera opción es agregar estas nuevas funcionalidades al sistema seleccionado • La otra opción se corresponde en implementar un sistema aparte que brinde estas funcionalidades. • La opción elegida es la de realizar un nueva aplicación que contemple las funcionalidades faltantes • Motivos: Se adquiere flexibilidad e independencia en cuanto al diseño y la implementación de la solución. Adopción e implementación del sistema

31. Sistemas Ganglia dopplerVUE CA eHealth Big Brother Zyrion Traverse Aarhus GroundWork Community CiscoWorks LMS Wormly Zenoss Zenoss GroundWork Enterprise Osmius Everest Hyperic Hyperic Heroix Longitude Opsview Pandora FMS Pandora FMS Hyperic Enterprise Xymon z/OS RMF NeDi Collectd fireScope BSM OpenNMS OpenNMS Uptime Software Entuity InterMapper Munin PacketTrap LoriotPro SevOne SolarWinds Cacti Nimsoft ManageEngine OpManager SNM WhatsUpGold Zabbix Zabbix Intellipool Network Monitor Nagios Nagios Polymon Plixer Scrutinizer freeNATS NetCrunch Performance Co-Pilot Server-Eye Seven-Layer Op5 Monitor Investigación Hyperic Pandora FMS Pandora FMS Nagios

32. Desarrollo Desarrollo

33. Introducción Pandora FMS es un software de Código Abierto que sirve para monitorizar y medir todo tipo de elementos. Monitoriza sistemas, aplicaciones o dispositivos. Permite saber el estado de cada elemento de un sistemas a lo largo del tiempo. Pandora FMS también puede monitorizar cualquier tipo de servicio TCP/IP, sin necesidad de instalar agentes, y monitorizar sistemas de red como balanceadores de carga, routers, switches, sistemas operativos, aplicaciones o impresoras si se necesita hacerlo de forma remota. Pandora FMS también soporta SNMP para recolectar datos o recibir traps. Pandora Desarrollo

34. Funcionalidades • Pandora FMS tiene varias funcionalidades, las más relevantes son: • Arquitectura modular y escalar. • Soporte para más de 2500 módulos (servicios) por servidor. • Disparar alertas cuando algo funciona mal • Usar agentes para recolectar información relevante de cada nodo Pandora Desarrollo

35. Ejemplos de monitoreos • Algunos ejemplos de recursos comunes que pueden ser monitorizados con Pandora FMS son: • la carga del procesador • el uso de disco y memoria • procesos que están corriendo en el sistema • eventos determinados en un log • factores ambientales como la temperatura, la luz o la humedad • valores de aplicaciones como determinados textos en una página web • En general cualquier cosa que se pueda recolectar de forma automatizada. Pandora Desarrollo

36. Qué es? • Sistema de código libre y multiplataforma creado para servir de interfaz entre celular y computador. • Dispone de interfaz gráfica y también uso mediante línea de comandos. • Funcionalidades • Manejo de mensajes • Manejo de agenda • Interfaz de llamadas • Para qué se usó? • Envío de SMS • Ventajas • Evitar dependencias de proveedores externos para envío de mensajes. Wammu Desarrollo

37. Generalidades y necesidad del proceso El sistema Signa Web necesita datos provenientes del subsistema de monitoreo PandoraFMS para poder realizar su operativa. Debido a que el sistema de monitoreo se desea mantener independiente a Signa Web, es necesario crear una serie de procedimientos para extraer, transformar y cargar la información pertinente. Debido a que la información existe a nivel exclusivo de base de datos, los procesos se implementan como procedimientos almacenados. Proceso ETL Desarrollo

38. Proceso ETL • Arquitectura a alto nivel del proceso • En forma conceptual existe una serie de componentes involucrados en el proceso. • Pandora DB: base de datos del sistema Pandora FMS • ETL DB: base de datos donde se ubican los procedimientos de extracción, transformación y carga. • Signa DB: base de datos del sistema Signa DB. • Proceso ETL: conjunto de procedimientos encargados del proceso. Desarrollo

39. Arquitectura a alto nivel del proceso En forma conceptual existe una serie de componentes involucrados en el proceso. Proceso ETL Desarrollo Proceso ETL Proceso ETL Signa DB Pandora DB Nuevo Sistema DB ETL DB

40. Proceso ETL • Generalidades del proceso • El proceso ETL consta de dos etapas netamente diferenciadas pero vinculadas entre sí: • Una etapa de filtrado, transformación y carga a entidades temporales de almacenamiento. • Una etapa de copiado de la información temporal a las tablas definitivas de la base de datos Signa. • El motivo de la existencia de estas dos fases separadas es proveer al usuario de un mayor control y seguridad en la información que está ingresando al sistema. Desarrollo

41. Generalidades del proceso En forma conceptual existe una serie de componentes involucrados en el proceso. Proceso ETL Petición de ejecución del proceso 1 Desarrollo Carga de información (temporal) 4 Proceso ETL Búsqueda de nuevos eventos e información asociada 3 Signa DB Pandora DB 5 Comprobación y chequeos 2 Transferencia de información (permanente) Registro del proceso 6 ETL DB

42. Surgieron durante la etapa de investigación • Los principales requerimientos del sistema son: • Reportes por tipo de costos según la siguiente clasificación: • Mantenimiento • Preventivo • Costo de defectos internos • Costo de defectos externos • Manejo de tareas y subtareas • Reporte de incidentes (permite diferenciar entre costos internos y externos) Requerimientos de SignaWeb Desarrollo

43. Diseño de SignaWeb Desarrollo

44. Se plantearon cuatro iteraciones para el desarrollo del mismo: Implementación de SignaWeb Desarrollo

45. Herramienta gerencial. • Complementa el sistema de monitoreo. • Permite seguimiento de eventos, tareas, subtareas y sus costos. • Ejecutan los servicios de importación de datos desde el sistema de monitoreo. SIGNA Web La interfaz de usuarios se diseño en base al diseño web de la aplicación de monitoreo con el fin de mantener una misma gama colores e imágenes, de forma de facilitar el aprendizaje y uso de las aplicaciones.

46. Totalmente flexible (Perfiles de Usuario) • Cada uno de los usuarios tiene un perfil asociado. • El perfil de un usuario representa un conjunto de permisos. • Los permisos representan cada una de las funcionalidades de SIGNA • Listados • Orden de columna • Paginado • Calendario • Fecha sin hora • Fecha con hora SIGNA Web

47. Administración de usuarios L, A, M, E, Bloquear usr y Restaurar contraseña Administración de Permisos L, A y M. Administración de Perfiles L, A, M y E. Administración de Incidentes L, A, M y E. Asociación de Eventos a Incidente Administración de Cotizaciones L, A, M y E. Administración de Tareas L, A, M y E. Administración de Subtareas de Tareas L, A y E. Administración de costos de subtareas A y M. Administración de Costos L, A, M y E. Administración de Items de Costos L, A y E. Administración de Conversiones de unidades L, A y E. Administración de Eventos L, A y E. Importación de datos del sistema de monitoreo Administración de sesiones de importación Transferencia de información Administración de configuraciones Cálculos de costos por alarma Reportes: Costos por tipos y Costos por servidor. SIGNA Web

48. Cotización. SIGNA Web

49. Costos por tipos. SIGNA Web

50. Costos por servidor. SIGNA Web