SIGNA
SIGNA
Sistema Integral Gestión y Notificación de Alarmas
Autores
Edgardo Silvera
Pablo Larraz
Walter Fernández
Tutor
Enrique Latorres
2009
Agenda
Introducción
Cliente
Fases del proyecto
Introducción
Investigación
Desarrollo
Conclusiones
Finalización
Introducción
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:
Consultoría
Investigación
Desarrollo
Cliente
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
•
•
•
•
•
Amenaza:
Tercerización
Mejorar el control de los servicios (automatizar)
Disminuir tiempos de respuesta
Crecimiento (nuevos servicios)
Personal limitado
Oportunidades:
Seguimiento de tareas y costos
Mejoras
Fases del proyecto
Introducción
• Análisis inicial
• Configuración de ambiente de trabajo
Investigación
• Selección del sistema de monitoreo y comprobación de
cumplimiento de todas las funcionalidades esperadas.
• Análisis de alternativas
Desarrollo
• Desarrollo de SignaWeb
• Implementación de procesos ETL
• Integración de Wammu
Finalización
• Establecimiento de conclusiones
• Integración de documentación
Introducción
Metodología
•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
http://sites.google.com/site/proyectosigna/
Introducción
Gestión de Proyecto
• Contacto
con el cliente
La gestión del proyecto tuvo en cuenta los siguientes
componentes:
• Comunicación
• Roles, tareas y división de trabajo
• Manejo de riesgos
• Hitos y entregables
• Versionado
• Control de calidad
•mail
•teléfono
• Responsables por fases
• Comunicación interna
• Marcelo: investigación de
•MSN
alternativas
de software
• Correcta
selección
de
•Mail
• Pablo: responsable del sistema
•teléfono
software
Signa
Web
•sitio
web
• Falta
de
experiencia
• Walter:
infraestructura, Pandora,
•• Coordinación
reuniones
Problemas
dede
comunicación
ETL
• Calendario
de
entregas
periódicas
•Cliente(cronograma)
internas
• Manejo
de repositorio de
•Interna
versionado (SVN)
• Convención de nombre para
•nombre
Revisión
deEjemplo;
decruzada
archivos.
Proyecto SIGNA [Documento - Actividades de
entregables
Relevamiento v0.2.09082422].doc
• Manejo de estándares
Alternativas
Investigación
Adquisición
de un sistema
opensource
Desarrollo
• No
completo
dereinventar la rueda
un sistema
• Costos
Adquisición
completo
de un(6sistema
• Tiempo limitado
meses)
de
• Aceptadocomercial
de riesgos
monitoreo
• Consultoría
Elección
Investigación
Proceso de Selección
Identifica tres etapas que se deben seguir para seleccionar de forma exitosa un
sistema de monitoreo y notificación:
Identificación de requerimientos
Búsqueda de sistemas candidatos
Selección del sistema apropiado en base
a una metodología
Investigación
Características y
requerimientos del sistema
• 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 a elegir
Investigación
•
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
Lista de Sistemas
• 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
Metodología de selección de
software
• 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
Investigación
Comparación entre las
Metodologías QSOS y BRR
• 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
QSOS: comparación más
universal
BRR: se adapta más a los
distintos contextos
Investigación
Selección de la Metodología
• 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
Investigación
Etapas de la metodología BRR
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
Selección primaria de sistemas
candidatos
•
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
Investigación
Selección primaria de sistemas
candidatos
•
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.
Investigación
Eliminación de sistemas
candidatos
•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:
Sistemas Pre Seleccionados
Hyperic HQ
Nagios
Open NMS
Pandora FMS
Zabbix
Zenoss
Investigación
Selección de sistemas finalistas
• 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.
Investigación
Sistemas Finalistas
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
Instalación y Descripción de los
sistemas finalistas
•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
Investigación
Selección y ponderación de
categorías y métricas
•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
Posición
Categoría
Peso
1
Funcionalidad
25,00%
2
Calidad
20,00%
3
Usabilidad
20,00%
4
Rendimiento
15,00%
5
Apoyo
10,00%
6
Comunidad
5,00%
7
Arquitectura
5,00%
8
Escalabilidad
0,00%
9
Seguridad
0,00%
10
Documentación
0,00%
11
Adopción
0,00%
12
Profesionalismo
0,00%
Investigación
Justificación de selección de
categorías
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
• 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
Selección del sistema
Los valores finales obtenidos de los sistemas son los siguientes:
Sistema
Puntuación BRR
Hyperic HQ
3,395
Nagios
3,605
Pandora FMS
3,785
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.
Investigación
Selección del sistema
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).
Investigación
Adopción del sistema
•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.
Investigación
Adopción e implementación del
sistema
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.
Sistemas
Investigación
Ganglia
dopplerVUE
Aarhus
GroundWork Community
CA eHealth
GroundWork Enterprise
Opsview
NeDi
Collectd
InterMapper
Cacti
OpenNMS
PacketTrap
Nagios
Performance Co-Pilot
Zyrion Traverse
Wormly
Hyperic
Hyperic Enterprise
Zenoss
Heroix Longitude
Xymon
z/OS RMF
Uptime Software
LoriotPro
ManageEngine OpManager
Intellipool Network Monitor
NetCrunch
Everest
fireScope BSM
Munin
Nimsoft
CiscoWorks LMS
Osmius
Pandora FMS
Big Brother
SevOne
SNM
Entuity
SolarWinds
WhatsUpGold
Polymon
Plixer Scrutinizer
Server-Eye
Seven-Layer
Zabbix
freeNATS
Op5 Monitor
Desarrollo
Desarrollo
Signa Web
Proceso
ETL
Wammu
Desarrollo
Pandora
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
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
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.
Desarrollo
Wammu
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.
Desarrollo
Proceso ETL
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.
Desarrollo
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
Proceso ETL
Arquitectura a alto nivel del proceso
En forma conceptual existe una serie de componentes involucrados en el proceso.
Proceso
ETL
Signa DB
Pandora
DB
Nuevo Sistema
DB
ETL DB
Desarrollo
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.
Proceso ETL
Desarrollo
Generalidades del proceso
En forma conceptual existe una serie de componentes involucrados en el proceso.
1 Petición de ejecución del proceso
Carga de información (temporal)
4
Proceso
ETL
Signa DB
3 Búsqueda de nuevos eventos e
información asociada
Pandora DB
5
2 Comprobación y chequeos
Transferencia de información
(permanente)
6 Registro del proceso
ETL DB
Desarrollo
Requerimientos de
SignaWeb
•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)
Desarrollo
Diseño de SignaWeb
Desarrollo
Implementación de
SignaWeb
Se plantearon cuatro iteraciones para el desarrollo del mismo:
Reportes
Costos de
mantenimiento
Costos de caída
Usuarios, perfiles y permisos
SIGNA Web
•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.
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.
SIGNA Web
•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
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
Cotización.
SIGNA Web
Costos por tipos.
SIGNA Web
Costos por servidor.
Finalización
Finalización
Integración de
documentación
Revisión general del
proyecto
Conclusiones
Conclusiones
Nuevos desafíos
Investigación
Implementación
• Entender el proyecto y organizarlo
• Analizar requerimientos del cliente
• Muchas opciones de sistemas open source
• Necesidad de buscar un proceso
• Implementación de sistemas finalistas
• Selección de sistema final
• Adecuación de la metodología
• Proceso ETL
• Lenguaje de desarrollo
• Wammu
• SignaWeb
Gracias !