SIGNA

SIGNASistema Integral Gestión y Notificación de Alarmas

AutoresEdgardo Silvera

Pablo LarrazWalter Fernández

TutorEnrique Latorres

2009

Agenda

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:

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

• Mejorar el control de los servicios (automatizar)• Disminuir tiempos de respuesta• Crecimiento (nuevos servicios)• Personal limitado• Seguimiento de tareas y costos

Amenaza:Tercerización

Oportunidades:Mejoras

Fases del proyecto

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/

Gestión de Proyecto

La gestión del proyecto tuvo en cuenta los siguientes componentes:• Contacto con el cliente•mail•teléfono

• Comunicación interna•MSN•Mail•teléfono•sitio web

• Coordinación de reuniones periódicas (cronograma)

• Responsables por fases• Marcelo: investigación de alternativas de software• Pablo: responsable del sistema Signa Web• Walter: infraestructura, Pandora, ETL

• Correcta selección de software• Falta de experiencia• Problemas de comunicación

•Cliente•Interna

• Calendario de entregas internas• Manejo de repositorio de versionado (SVN)• Convención de nombre para nombre de archivos. Ejemplo; Proyecto SIGNA [Documento - Actividades de Relevamiento v0.2.09082422].doc

• Revisión cruzada de entregables• Manejo de estándares

• Comunicación

• Roles, tareas y división de trabajo

• Manejo de riesgos

• Hitos y entregables

• Versionado

• Control de calidad

Alternativas

• No reinventar la rueda • Costos

• Tiempo limitado (6 meses)• Aceptado de riesgos

• Consultoría

Proceso de Selección

Identifica tres etapas que se deben seguir para seleccionar de forma exitosa un sistema de monitoreo y notificació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

• 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.

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

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

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ónQSOS: comparación más

universal

BRR: se adapta más a los distintos contextos

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

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

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

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.

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

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.

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 reconocimientoEs uno de los sistemas más usados y más conocidos de esta familiaGran 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.

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

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%

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

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.

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.

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).

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.

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.

Aarhus

Big BrotherCA eHealth

Cacti

CiscoWorks LMS

Collectd

dopplerVUE

Entuity

Everest

fireScope BSM

freeNATS

Ganglia

GroundWork Community

GroundWork Enterprise Heroix LongitudeHyperic

Hyperic Enterprise

Intellipool Network Monitor

InterMapper LoriotPro

ManageEngine OpManager

Munin

Nagios

NeDi

NetCrunch

Nimsoft

Op5 Monitor

OpenNMS

Opsview

Osmius

PacketTrap

Pandora FMS

Performance Co-Pilot

Plixer ScrutinizerPolymon

Server-Eye Seven-Layer

SevOne

SNM

SolarWinds

Uptime Software

WhatsUpGold

Wormly

Xymon z/OS RMF

Zabbix

Zenoss

Zyrion Traverse

Sistemas

Pandora FMS

Nagios

Hyperic

Zenoss

Zabbix

OpenNMS

Hyperic

Pandora FMS

Nagios

Pandora FMS

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 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 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.

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.

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.

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.

Proceso ETL Arquitectura a alto nivel del proceso

En forma conceptual existe una serie de componentes involucrados en el proceso.

ProcesoETL

Pandora DB

ETL DB

Signa DB Nuevo Sistema DB

ProcesoETL

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 Generalidades del proceso

En forma conceptual existe una serie de componentes involucrados en el proceso.

ProcesoETL

Pandora DB

ETL DB

Signa DB

1 Petición de ejecución del proceso

2 Comprobación y chequeos

3 Búsqueda de nuevos eventos e información asociada

Carga de información (temporal) 4

Transferencia de información (permanente)

5

6 Registro del proceso

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)

Diseño de SignaWeb

Implementación de SignaWeb

Se plantearon cuatro iteraciones para el desarrollo del mismo:

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 IncidenteAdministració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 monitoreoAdministración de sesiones de importaciónTransferencia de informaciónAdministración de configuracionesCálculos de costos por alarmaReportes: Costos por tipos y Costos por servidor.

SIGNA Web Cotización.

SIGNA Web Costos por tipos.

SIGNA Web Costos por servidor.

Finalización

Conclusiones

Gracias !