[Documento - Aplicaciones de Monitoreo v5.0.09092103]

Estudio
de
alternativas
de
código
abierto
1
Índice
1.
2.
3.
Objetivo .................................................................................................................... 5
Situación actual ........................................................................................................ 5
Proceso de selección de Software ............................................................................. 5
3.1. Requerimientos que debe cumplir el sistema a elegir ...................................... 8
3.1.1.
Requerimientos del cliente ....................................................................... 8
3.1.2.
Sistemas de monitoreo con o sin agentes ................................................. 8
3.2. Selección primaria de sistemas candidatos ..................................................... 10
3.2.1.
Filtros aplicados para la eliminación de sistemas .................................. 10
3.2.2.
Sistemas candidatos ................................................................................ 11
3.2.2.1.
Argus .............................................................................................. 11
3.2.2.2.
Big Brother .................................................................................... 11
3.2.2.3.
CA eHealth .................................................................................... 12
3.2.2.4.
Cacti ............................................................................................... 12
3.2.2.5.
CiscoWorks LMS ......................................................................... 12
3.2.2.6.
Colletd ............................................................................................ 13
3.2.2.7.
DopplerVUE .................................................................................. 13
3.2.2.8.
Entuity ............................................................................................ 14
3.2.2.9.
Everest........................................................................................... 14
3.2.2.10. FireScope BSM ............................................................................ 14
3.2.2.11. FreeNATS Network Monitor ....................................................... 15
3.2.2.12. Ganglia .......................................................................................... 15
3.2.2.13. GroundWork Monitor Community .............................................. 15
3.2.2.14. GroundWork Monitor Enterprise ................................................ 16
3.2.2.15. Heroix Longitude .......................................................................... 16
3.2.2.16. Hyperic Open Source .................................................................. 17
3.2.2.17. Hyperic Enterprise ....................................................................... 17
3.2.2.18. Intellipool Network Monitor ......................................................... 18
3.2.2.19. InterMapper................................................................................... 18
3.2.2.20. Loriot Pro ....................................................................................... 18
3.2.2.21. Manage Engine OPManager ..................................................... 19
3.2.2.22. Munin ............................................................................................. 19
3.2.2.23. Nagios ............................................................................................ 20
3.2.2.24. NeDi ............................................................................................... 20
3.2.2.25. NetCrunch ..................................................................................... 21
3.2.2.26. Nimsoft........................................................................................... 21
3.2.2.27. OP5 Monitor .................................................................................. 21
3.2.2.28. OpenNMS ..................................................................................... 22
3.2.2.29. Opsview ......................................................................................... 22
3.2.2.30. Osimus........................................................................................... 23
3.2.2.31. PacketTrap .................................................................................... 24
3.2.2.32. Pandora FMS ............................................................................... 24
3.2.2.33. Performance CoPilot ................................................................... 25
3.2.2.34. Plixer Scrutinizer .......................................................................... 25
3.2.2.35. Polymon......................................................................................... 25
3.2.2.36. Server Eye .................................................................................... 26
3.2.2.37. Seven Layer .................................................................................. 26
2
3.2.2.38. SevOne .......................................................................................... 27
3.2.2.39.
SNM ............................................................................................... 27
3.2.2.40. Solar Winds................................................................................... 28
3.2.2.41. Uptime Software........................................................................... 28
3.2.2.42. What’s up Gold ............................................................................. 28
3.2.2.43. Wormly........................................................................................... 29
3.2.2.44. Xymon ............................................................................................ 29
3.2.2.45. Z/OS RMF ..................................................................................... 30
3.2.2.46. Zabbix ............................................................................................ 30
3.2.2.47. Zenoss ........................................................................................... 31
3.2.2.48. Zyrion Traverse ............................................................................ 31
3.2.2.49. Listado resumido de Sistemas .................................................. 32
3.3. Selección de los sistemas finalistas ................................................................ 34
3.4. Descripción de los sistemas finalistas ............................................................ 36
3.4.1.
Hyperic HQ ............................................................................................ 36
3.4.1.1.
Descripción general (funcionalidades y arquitectura) ............ 36
3.4.1.2.
Productos ...................................................................................... 36
3.4.1.3.
Funcionalidades ........................................................................... 36
3.4.1.4.
Estructura ...................................................................................... 37
3.4.1.4.1. Agente HQ ................................................................................ 38
3.4.1.4.2. Servidor HQ y la base de datos ............................................ 38
3.4.1.4.3. Interfaz de usuarios ................................................................ 38
3.4.1.4.4. HQ API ...................................................................................... 38
3.4.1.4.5. Complementos (Plugins) ........................................................ 38
3.4.1.4.6. Inventario y modelo de acceso a datos ............................... 39
3.4.1.5.
Requerimientos de Instalación .................................................. 39
3.4.1.5.1. Servidor Hyperic ...................................................................... 39
3.4.1.5.1.1. Entorno en tiempo de ejecución Java (JRE) ............... 40
3.4.1.5.1.2. Recursos para instalar el servidor Hyperic. ................. 40
3.4.1.5.1.3. Sistema Operativo ........................................................... 40
3.4.1.5.1.4. Librerías para plataformas basadas en UNIX ............. 40
3.4.1.5.2. Base de datos de Hyperic ...................................................... 41
3.4.1.5.2.1. Bases de datos que soporta el sistema ....................... 41
3.4.1.5.2.2. Hardware para la Base de datos ................................... 41
Recursos necesarios para la instalación de la base de datos de Hyperic .................... 41
3.4.1.5.3. Browsers soportados por el sistema .................................... 42
3.4.1.5.4. Agente HQ ................................................................................ 42
3.4.1.5.4.1. Recursos necesarios para instalar el agente HQ ....... 42
Recursos necesarios para la instalación de los agentes de Hyperic ............................ 42
3.4.1.5.4.2. Sistema Operativo para instalar el agente................... 42
3.4.1.5.4.3. Entorno en tiempo de ejecución Java (JRE). .............. 42
3.4.1.6.
Instalación ..................................................................................... 42
3.4.1.6.1. El script de Instalación ........................................................... 43
Parámetros de Instalación de Hyperic ........................................................................ 43
3.4.1.6.2. Ejecutar el procedimiento de instalación ............................. 43
3.4.1.7.
Integración con otros sistemas .................................................. 44
3.4.2.
Nagios ..................................................................................................... 44
3.4.2.1.
Características y funcionalidades ............................................. 44
3.4.2.1.1. Monitoreo completo de la red ................................................ 44
3.4.2.1.2. Funcionalidades básicas ........................................................ 44
3
3.4.2.1.3. Arquitectura fácilmente extensible ....................................... 45
3.4.2.1.4. Estable confiable y con una plataforma respetada ............ 45
3.4.2.1.5. Código personalizable ............................................................ 45
3.4.2.2.
Estructura ...................................................................................... 45
3.4.2.3.
Requerimientos de instalación................................................... 46
3.4.2.4.
Instalación ..................................................................................... 47
3.4.3.
Pandora FMS .......................................................................................... 47
3.4.3.1.
Características y funcionalidades ............................................. 48
3.4.3.1.1. Monitoreos mediante agentes ............................................... 48
3.4.3.1.2. Monitoreos sin agentes (monitorización remota) ............... 49
3.4.3.2.
Arquitectura................................................................................... 49
3.4.3.3.
Requerimientos de instalación................................................... 50
3.4.3.3.1. Servidores ................................................................................ 50
3.4.3.3.1.1. Servidor de datos de Pandora FMS ............................. 50
3.4.3.3.1.2. Servidor de red de Pandora FMS ................................. 51
3.4.3.3.1.3. Servidor de reconocimiento de red (recon) ................. 52
3.4.3.3.2. Agentes ..................................................................................... 52
3.4.3.3.2.1. Agentes Unix .................................................................... 52
3.4.3.3.2.2. Agentes Windows ............................................................ 52
3.4.3.4.
Instalaciones ................................................................................. 53
3.4.3.4.1. Instalación automática con el instalador ............................. 53
3.4.3.4.2. Instalación de la base de datos ............................................ 53
3.4.3.4.3. Instalar la consola web ........................................................... 53
3.5. Puntuación de los sistemas finalistas .............................................................. 53
3.5.1.
Ponderación de Categorías ..................................................................... 54
3.5.2.
Selección de los factores de ponderación adecuada ............................... 54
3.5.3.
Ponderación de Métricas por categorías ................................................. 55
3.5.4.
Métricas de Funcionalidad...................................................................... 56
3.5.5.
Recolección de datos .............................................................................. 58
3.5.6.
Selección del sistema .............................................................................. 58
3.6. Pruebas básicas de funcionamiento de Pandora Fms. .................................... 61
4
1. Objetivo
El objetivo de este documento es la presentación y evaluación de las herramientas de
código abierto más difundidas que provean una solución razonablemente similar a la
que se necesita en el proyecto SIGNA. Luego de evaluados los distintos sistemas
candidatos se procederá a la selección del más apropiado. La selección de este
sistema se realizara tomando como base el procedimiento descrito en el documento
“Proceso de Selección del Software.doc”.
2. Situación actual
En la actualidad el cliente mantiene bajo su control un conjunto heterogéneo de
dispositivos conectados a la red que proporcionan varios servicios. Este control implica
el mantenimiento de los dispositivos en forma preventiva y también la necesidad de
responder en tiempo y forma ante eventuales caídas de servicios. Actualmente se
carece de una notificación temprana y eficaz de las fallas que puedan ocurrir dentro
del conjunto de dispositivos mantenidos, el fallo se detecta cuando se recibe la
notificación de un usuario o por algún control realizado por operarios del centro de
cómputos; ante esta situación y por la necesidad de detectar caídas de servicios que
se tornan vitales, para el cliente de forma más rápida y segura surge la necesidad de
implantar una solución que provea la detección automática de fallas y notifique al
personal sobre sus ocurrencias. Esta solución puede consistir en la instalación de un
nuevo sistema que monitoree, identifique problemas y los notifique a las personas
indicadas para su resolución.
3. Proceso de selección de Software
El proceso de análisis y búsqueda del sistema que necesita el cliente va a consistir en
una serie de pasos netamente diferenciados y organizados. Se desarrolla en base al
documento “Proceso de selección de Software”. De este surgen tres fases que se
exponen en este documento. Además de estas, se prevé la existencia de una nueva
fase que abarca las tareas de adaptación (solo en caso de ser necesario) e
implementación del sistema en el cliente. Esta fase no forma parte de la selección del
sistema y no se expone sobre ella ni sus tareas en este documento.
Las fases que se implementarán se descomponen en las siguientes tareas:

Fase 1: Identificación de requerimientos.
o
Identificación de requerimientos del cliente: en esta tarea se deben
identificar los requerimientos funcionales y no funcionales del cliente,
generando una lista de requerimientos.
o
Otros requerimientos identificados.
5


Fase 2: Buscar sistemas que se ajusten a los requerimientos.
o
Identificación rápida de software preexistente: consiste en realizar la
búsqueda genérica de soluciones de software que estén previamente
realizadas y probadas.
o
Se genera una lista con los sistemas candidatos encontrados.
Fase 3: Seleccionar el sistema que más se adecue al contexto del proyecto
del conjunto de sistemas encontrados. En este punto usaremos la metodología
BRR que fue previamente analizada y seleccionada en el documento “Proceso
de Selección del Software.doc”.
o
Valoración de alternativas: a partir de la lista de sistemas se procede a
valorar los mismos de acuerdo a los criterios establecidos de antemano.
o
Filtrado de alternativas: de las alternativas posibles se realiza un filtrado
para determinar aquellos sistemas que van a pasar a la fase de pruebas
preliminares.
o
Elección de los tres o cuatro sistemas finalistas que cumplen con la
mayor cantidad de características que se buscan en el sistema. Los
sistemas elegidos en este punto son aquellos que se destacan de forma
positiva del resto de los sistemas candidatos.
o
Instalación y descripción de los sistemas finalistas, esta descripción
permitirá tener una aproximación mas exacta al las características de
cada sistema en cuanto a su estructuras, funcionamiento, instalación,
etc. Estas tareas no están propuestas por la metodología BRR pero el
equipo de proyecto considera que son necesarias y deben ser
realizadas para tener una visión global de los sistemas finalistas.
o
Aplicación del sistema de puntuación de la metodología BRR para cada
uno de los sistemas finalistas.
o
Elección: indica la selección del sistema mas apropiado al proyecto, en
base a las puntuaciones obtenidas en el punto anterior y otros factores
que el equipo de proyecto considere deban ser tenidos en cuenta.
o
Pruebas de funcionamiento del sistema elegido: se realizarán las
pruebas necesarias para confirmar el buen funcionamiento de la
aplicación.
6

Fase 4: Adaptación e implantación del sistema en el cliente.
o
Adaptación: en esta etapa se evalúa si el sistema seleccionado en la
fase 3 cumple con todas los requerimientos funcionales planteados por
el cliente. En caso de que el sistema sea lo suficientemente completo
como para realizar las funciones marcadas como requerimientos no es
necesario adaptarlo, pero si existe la necesidad de agregar alguna
funcionalidad especifica que el sistema no cubre, se evaluara la
posibilidad de extender el sistema y cubrir esas necesidades no
cubiertas.
o
Implantación: son las tareas de implantación del producto en el cliente.
Figura 1 – Diagrama de flujo de los procesos expuestos
7
3.1. Requerimientos que debe cumplir el sistema a elegir
3.1.1. Requerimientos del cliente
Los requerimientos del cliente están detallados en el documento de “Especificación de
requerimientos”. En esta sección se hace una simple enumeración de los puntos
principales del mismo para establecer una mínima información de contexto.
De acuerdo con la primer etapa del proceso se identifican los requerimientos
generales funcionales del producto que son básicamente: proveer de una forma rápida
de notificación ante las fallas que ocurran en alguno de los dispositivos conectados en
la red de monitoreo y la posibilidad de disponer de una forma cuantificable mediante
reportes de los costos de calidad que puedan tener las fallas ocurrentes. Además la
posibilidad de generación de otros reportes que ayuden a la gerencia a detectar
situaciones problemáticas.
De acuerdo a lo planteado por el cliente se identifican los siguientes requerimientos
funcionales y no funcionales que debe cumplir el sistema de monitoreo.











Debe ser un sistema Open Source
Debe monitorear al menos 15 componentes.
Se debe poder implementar sobre cualquier sistema operativo.
Debe poder monitorear distintas plataformas.
La aplicación de monitorización debe vigilar sistemas y aplicaciones.
Debe monitorear hardware y software tales como (aplicaciones, Sistemas
Operativos, bases de datos, servidores web, VPN, procesos, servicios, etc.).
Debe detectar interfaces de red caídas.
Debe enviar mensajes SMS informando cuando falle algún sistema o aplicación
que se considere esencial.
Debe generar alertas cuando se sobrepasen umbrales definidos.
Debe generar informes, estadísticas.
Debe monitorear cortafuegos, proxies, routers, switches.
3.1.2. Sistemas de monitoreo con o sin agentes
A continuación se realizara una comparación de los sistemas de monitoreo que tienen
agentes y aquellos que no lo tienen. Para esta sección del documento nos basamos
en Chris Knowles (2007) [1] quien realiza una comparación detallada del tema. Esta
información es importante para ser evaluada como requerimiento no funcional del
sistema.
El agente de un sistema de monitoreo es un componente de software. Generalmente
es una pequeña aplicación que reside en el cliente y recoge datos. Los datos se
envían al servidor central de la aplicación en base a 2 opciones. La primera opción es
que el envío de datos sea administrado por el agente local, o este sea administrado
por la estación de monitoreo central.
8
Los sistemas que tienen la política de envío de información al servidor administrada
por el agente ubicado en el cliente, tienen como desventaja que pueden generar
cargas de trabajo en los equipos clientes. Por lo tanto es deseable que las políticas de
envío de información sean administradas por el servidor y no por el agente.
En la tabla 1 se expone un cuadro de ventajas y desventajas de sistemas con agentes
y sistemas sin agentes.
Ventajas
Sistemas con agentes
 Información más específica y más
detallada.
 Mayor flexibilidad para realizar
monitoreos personalizable.
 Posibilidad de crear soluciones de
monitoreos que controlen estados
de servicios o métricas no
estándares sobre aplicaciones o
hardware.
 El control de las aplicaciones y
servicios se realiza directamente
en el nodo monitoreado.
 Mayor seguridad en la red ya que
se
manejan
protocolos
propietarios de encriptación.
 Menor riesgo de detección de
inactividades.

Desventajas
Ventajas
Puede provocar mayor carga de
actividad en el cliente
 Se debe instalar el agente en
todos los equipos que se van a
monitorear.
Sistemas sin agentes
 No hay que instalar el agente en
el cliente
 No se genera carga de trabajo en
el cliente
 Es una opción para casos en los
que no es posible instalar
aplicaciones en los clientes

Tiene métricas menos especificas
por consiguiente se pueden
realizar análisis menos detallados.
 Pueden ser afectadas por hechos
que sucedan en la red.
Desventajas
 El desarrollo de complementos
puede ser mas complicado, o
directamente
imposibles
de
realizar.
 No son seguros.
Tabla 1: Ventajas y desventajas de los agentes en sistemas de monitoreo.
9
Las soluciones basadas en agentes instalados en el cliente brindarán acceso a más
información y con métricas más detalladas, este hecho puede ser importante para
disminuir el tiempo de detección de fallos, mientras que soluciones sin agentes le
permiten al fabricante evitar la etapa de desarrollo del agente pero con el riesgo de
obtener menos datos y en un entorno menos seguro. En base a lo expuesto, y
teniendo en cuenta las ventajas y desventajas ya nombradas anteriormente de ambas
soluciones se agrega como requerimiento no funcional la característica de tener en su
estructura el uso de un agente en el cliente.
3.2. Selección primaria de sistemas candidatos
3.2.1. Filtros aplicados para la eliminación de sistemas
Para eliminar algunos productos de forma rápida la metodología BRR propone evaluar
características de los sistemas de la lista. Algunas características se obtienen de las
sugeridas por la metodología y otras se obtienen según el propio contexto de este
proyecto. Los siguientes indicadores sirven como fuente de comparación y se ordenan
según su importancia de mayor a menor, y estos son:
(a) El 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.
(b) Evaluar el tipo de licencia, el sistema debe ser de código abierto (Open Source)
(c) El Sistema debe poder monitorear al menos 15 componentes.
(d) 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.).
(e) Debe monitorear servidores con sistemas operativos Windows, Linux y Unix.
(f) El servidor se debe poder instalar en Linux.
(g) Debe generar alertas cuando se identifican situaciones que así lo ameriten.
(h) Los datos se deben poder exportar a una base relacional open source.
(i) El sistema debe trabajar con agentes instalados en los equipos clientes.
(j) Permite generar complementos (plugs in) y brinda información de cómo
desarrollarlos.
(k) Existe documentación suficiente y clara disponible del sistema.
(l) El sistema tiene una comunidad que lo respalde.
(m) El sistema es muy conocido o utilizado. Existencia de empresas clientes o
usuarios a los que se puede referenciar.
(n) El sitio del sistema tiene un diseño profesional.
(o) Existen soluciones a errores encontrados. Se han publicado nuevas versiones
o nuevos paquetes en el último año.
El sistema elegido debe cumplir con una serie de atributos que son mínimos e
indispensables para su elección. Estos atributos son los expuestos desde el numeral
(a) hasta el numeral (k). Si alguno de estos puntos no esta contemplado en el sistema,
este se eliminara de la lista de forma automática.
10
3.2.2. Sistemas candidatos
En esta etapa se realiza una lista de los posibles sistemas candidatos, y la aplicación
de los filtros planteados en el punto anterior. La forma de filtrar los sistemas será la
siguiente:

Se elige el sistema a evaluar

Se evaluará si cumplen con los atributos de comparación que figuran en el
punto anterior. La evaluación se realizará siguiendo el orden indicado según su
importancia. En caso de encontrar que un sistema no cumple con un atributo, o
la información disponible no es suficiente para determinar si el sistema cumple
o no con el requisito, se descarta de la lista sin tener la necesidad de seguir
evaluando los próximos atributos. Los sistemas candidatos son los siguientes:
3.2.2.1. Argus
Sitio Oficial: http://argus.tcp4me.com/
Aarhus
Atributo
(a)
(b)
(c)
(d)
Comentario
Evaluación
Cumple
Cumple
Cumple
No queda claro si puede monitorear
el uso de memoria, disco o CPU de Sin Información
un servidor
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
No se aprecia mayor soporte o pruebas de uso extendido y fundamentados por parte
de otras empresas. La interfaz es bastante sencilla. No presenta pruebas de creación
o adaptación de plugins.
3.2.2.2. Big Brother
Sitio Oficial: http://bb4.com/
Big Brother
Atributo
(a)
(b)
Comentario
Sistema con licencia comercial
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema comercial bastante conocido y referenciado en varios sitios de Internet.
Aparentemente es un sistema estable que monitorea y diagnostica todo tipo de
11
componentes de una red, dispositivo, o servidor (Windows, Linux, Unix) desde un
browser a través de una aplicación web.
3.2.2.3. CA eHealth
Sitio Oficial: http://www.ca.com/us/network-performance.aspx
NetCrunch
Atributo
(a)
(b)
Comentario
Sistema con licencia comercial
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial. Tiene algunos clientes comerciales de
importancia. Tiene buena documentación. No presenta posibilidad de creación de
plugins. No tiene un enfoque preciso en la monitorización de sistemas.
3.2.2.4. Cacti
Sitio Oficial: http://www.cacti.net/
Cacti
Atributo
(a)
(b)
(c)
(d)
Comentario
No monitorea el uso de memoria,
disco o CPU de un servidor.
Evaluación
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
No cumple
Pagina Oficial
Cacti es una aplicación que brinda una solución de gráficos de red diseñado para
aprovechar las funcionalidades de rrdtool1, y su objetivo no pasa en el monitoreo de
componentes, sino en la generación de gráficos.
3.2.2.5. CiscoWorks LMS
Sitio Oficial: http://www.cisco.com/en/US/products/sw/cscowork/ps2425/index.html
1
RRDtool - Round Robin Database tool. Es el estándar de la industria OpenSource para el registro de
datos de alto rendimiento, es un sistema de representación gráfica de datos. Permite que shell scripts
personalizados o aplicaciones completas los usen.
12
CiscoWorks LMS
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial. Es una aplicación propietaria que permite
realizar el monitoreo de redes CISCO.
3.2.2.6. Colletd
Sitio Oficial: http://collectd.org/
Collectd
Atributo
(a)
(b)
(c)
(d)
Comentario
Solo realiza monitoreos básicos, el fin
del sistema no es el monitoreo de
componentes.
Evaluación
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
No cumple
Pagina Oficial
Collectd es un sistema Open Source orientado recoger estadísticas de rendimiento de
sistemas periódicamente y proporciona mecanismos para almacenar los valores
recogidos de distintas maneras, por ejemplo: en archivos RRD2.
En su pagina web especifica que su fin no es ser un sistema de monitoreo aunque
permite realizar algunos monitoreos simples y enviar notificaciones.
3.2.2.7. DopplerVUE
Sitio Oficial: http://www.dopplervue.com/
DopplerVUE
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial. Tiene un interesante sitio web que permite
observar demostraciones del sistema. No existe foro de ayuda, sin embargo hay
documentación bien estructurada. No se aprecian clientes de importancia a través del
sitio.
2
Archivos RRD – Son archivos usados por la aplicación RRDTool.
13
3.2.2.8. Entuity
Sitio Oficial: http://www.entuity.com/
Entuity
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Entuity es un sistema con licencia comercial. No existe foro de ayuda, sin embargo hay
documentación accesible. No se aprecian clientes de importancia a través del sitio
web, aunque es un producto galardonado que cuenta con varios reconocimientos que
se exponen en su sitio.
3.2.2.9. Everest
Sitio Oficial: http://www.lavalys.com/
Everest
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial que provee en sus sitio versiones de testeo del
producto, es una herramienta desarrollada para realizar la gestión informática y de
seguridad. Tiene algunos clientes comerciales de importancia. Tiene buena
documentación y foro de consultas.
3.2.2.10. FireScope BSM
Sitio Oficial: http://www.firescope.com/Products/BSM/
FireScope BSM
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial. El sitio no brinda mucha información del
producto pero parece ser un completo sistema de monitoreo. Aunque tiene muchos
clientes indicados en el sitio, no se puede saber quienes son.
14
3.2.2.11. FreeNATS Network Monitor
Sitio Oficial: http://www.purplepixie.org/freenats/
FreeNATS Network Monitor
Atributo
(a)
Comentario
-
Evaluación
No Cumple
Fuente
Pagina Oficial
Es un sistema Open Source al cual se encuentra aún en desarrollo. Por el momento
plantea ser una alternativa muy simple de monitoreo de pequeñas redes no muy
sofisticadas.
3.2.2.12. Ganglia
Sitio Oficial: http://ganglia.info/
Ganglia
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Comentario
El sistema monitorea componentes
pero no genera alarmas
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
No Cumple
Pagina Oficial
Es un sistema de monitoreo escalable y distribuido orientado para sistemas de alta
perfomance como clusters y grids con la capacidad de funcionar sobre varios sistemas
operativos y varias estructuras de procesador, y esta en funcionamiento en
importantes clientes, pero aparentemente es solo un sistema de monitoreo que no esta
orientado a generar y enviar alarmas.
3.2.2.13. GroundWork Monitor Community
Sitio Oficial: http://www.groundworkopensource.com/community/
GroundWork Monitor Community
Atributo
(a)
(b)
(c)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
15
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
No se encuentra documentación
disponible sobre el sistema, excepto
un manual de instalación.
-
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
?
Pagina Oficial
Cumple
Cumple
Cumple
Cumple
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
GroundWork Monitor Community Edition es un sistema que cumple con todos los
requisitos básicos planteados por nuestro cliente excepto la generación de reportes,
de todas formas pasa a ser un sistema candidato en caso de no encontrar sistemas
que cumplan con todas las características esperadas.
3.2.2.14. GroundWork Monitor Enterprise
Sitio Oficial: http://www.groundworkopensource.com/products/enterprise/
Ganglio
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
GroundWork Monitor tiene 4 productos con características bien diferenciadas, estos
son: Community Edition (expuesto en el punto anterior), Starter Edition, Professional
Edition y Enterprise Edition pero a excepción del producto Community Edtion, los otros
3 productos se distribuyen con licencia comercial.
3.2.2.15. Heroix Longitude
Sitio Oficial: http://www.heroix.com/
Heroix Longitude
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
16
Heroix Longitude es un sistema con licencia comercial. Tiene algunos clientes
comerciales de importancia. Tiene buena documentación y demostraciones del
producto en si sitio web.
3.2.2.16. Hyperic Open Source
Sitio Oficial: www.hyperic.com
Hyperic Open Source
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-.
-.
-.
-.
-.
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Hyperic es un sistema que cumple con todos los requisitos básicos planteados por
nuestro cliente por consiguiente pasa a ser un sistema candidato con posibilidades de
ser un sistema finalista.
3.2.2.17. Hyperic Enterprise
Sitio Oficial: www.hyperic.com
Hyperic Enterprise
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Hyperic Enterprise se distribuye con licencia comercial.
17
3.2.2.18. Intellipool Network Monitor
Sitio Oficial: http://www.intellipool.se/
Intellipool Network Monitor
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Intellipool Network Monitor es un sistema con licencia comercial. Tiene algunos
clientes comerciales de importancia. Es un sistema que no necesita instalar agentes
en los equipos monitoreados. Es escalable y permite monitorear fácilmente de 2 a
1500 clientes.
3.2.2.19. InterMapper
Sitio Oficial: http://www.intermapper.com/
InterMapper
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
InterMapper es un sistema con licencia comercial que permite ver y controlar los
componentes de la red en tiempo real, permite realizar monitoreos en línea y generar
alarmas, crear reportes para realizar diagnósticos, y provee a sus usuarios de otras
funcionalidades. Cumple con las características solicitadas.
3.2.2.20. Loriot Pro
Sitio Oficial: http://www.loriotpro.com/
Loriot Pro
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Loriot Pro tiene 3 productos distintos con diferentes características: Free, Lite,
Estándar y Extended Edition. Solo la primera es de distribución libre, no es un software
open source. La versión libre del software tiene limitaciones importantes, por ejemplo
solo permite monitorear hasta 10 nodos.
18
3.2.2.21. Manage Engine OPManager
Sitio Oficial: http://www.manageengine.com/products/opmanager/
Manage Engine OPManager
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Manage Engine OpManager tiene 4 productos disponibles con diferentes
características: Free, Deluxe, Essential y Professional Edition. Solo la primera es de
distribución libre, no es un software open source. La versión libre del software tiene
limitaciones importantes, por ejemplo solo permite monitorear hasta 10 nodos, y
cuenta solo las opciones más básicas de monitoreo disponibles.
3.2.2.22. Munin
Sitio Oficial: http://munin.projects.linpro.no/
Munin
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Munin es un sistema open source que podría ser elegido como sistema finalista ya que
cumple con todos las características obligatorias que se requieren del sistema. Es
necesario investigar respecto al manejo de datos si existe alguna forma de registrar los
datos en una base MySql. Por otro lado no se observan clientes importantes que
utilicen el sistema.
19
3.2.2.23. Nagios
Sitio Oficial: http://www.nagios.org/
Nagios
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Nagios es un sistema open source que cumple con todas las características que se
requieren del sistema a elegir. Posee importantes clientes, es un sistema referente en
la familia de los sistemas de monitoreo. Cuenta con una cantidad importante de
plugins y de sistemas que se basan en sus funcionalidades. Es un candidato
importante como para ser elegido como sistema finalista.
3.2.2.24. NeDi
Sitio Oficial: http://www.nedi.ch/
NeDi
Atributo
(a)
Comentario
-
Evaluación
No Cumple
Fuente
Pagina Oficial
NeDi es un sistema open source que parece estar en una etapa de desarrollo. El sitio
indica que es un sistema que puede crecer pero que esta en una etapa en la que
todavía no es confiable como para ser utilizado en este proyecto.
20
3.2.2.25. NetCrunch
Sitio Oficial: http://www.adremsoft.com/netcrunch/
NetCrunch
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema con licencia comercial. Es usado por clientes comerciales de mediana
importancia. El sistema cuenta con una cantidad importante de reglas de monitoreo
predefinidas aplicables a importantes sistemas de hardware y sotware tales como ISS,
MySQL, CISCO, etc. Cumple con los requerimientos del cliente.
3.2.2.26. Nimsoft
Sitio Oficial: http://www.nimsoft.com/
Nimsoft
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Nimsoft es un sistema con licencia comercial que tiene clientes comerciales de
importancia. Cumple con las funcionalidades solicitadas por el cliente del proyecto. Se
destaca en su sitio web testimonios de sus clientes exponiendo las cualidades del
producto.
3.2.2.27. OP5 Monitor
Sitio Oficial: http://www.op5.se/nyheter/201-op5-releases-new-version-of-op5-monitor-
Op5 Monitor
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
La base de OP5 Monitor es el popular y galardonado proyecto de código abierto
Nagios. OP5 ha unido el sistema Nagios con distintos agregados que potencian el
reconocido sistema con nuevos informes, configuración mas sencilla y rápida, se
agregan más de 200 plugins y otras utilidades al proyecto de código abierto como
MySQL, NSClient y CentOS. OP5 Monitor propone agregar nuevas características,
21
funcionalidades, facilidad de uso, estabilidad, seguridad y apoyo a un producto ya
existente; además de incluir las actualizaciones del producto con el fin de lograr la
optimización del mismo para un uso profesional.
3.2.2.28. OpenNMS
Sitio Oficial: http://www.opennms.org/index.php/Main_Page
OpenNMS
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
OpenNMS es un sistema open source que cumple con todas las condiciones
necesarias como para ser elegido como sistema finalista. Cuenta con clientes que
monitorean importante cantidad de nodos. Utiliza como repositorio de datos
PostreSQL.
3.2.2.29. Opsview
Sitio Oficial: http://www.opsview.org/
Opsview
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
22
(i)
(j)
(k)
(l)
(m)
(n)
(o)
-
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Opsview es un sistema open source que cumple con todas las condiciones necesarias
como para ser elegido como sistema finalista. En su estructura, el núcleo del sistema
esta compuesto por Nagios. Entre sus características más relevantes se observan que
puede monitorear un número muy importante de nodos debido a que su estructura
esta pensada para que el sistema sea escalable y fácil uso. No se identifican clientes
de importancia del sistema.
3.2.2.30. Osimus
Sitio Oficial: http://www.osmius.net/es/
Osimus
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Osimus parece ser un sistema muy interesante, de fácil uso y de interfaces muy
amigables, puede monitorear todo lo que es requerido por nuestro cliente, en su
pagina oficial no se hace referencia a clientes de importancia que lo haya elegido
como solución. Es un sistema que con posibilidades de ser elegido como sistema
finalista.
23
3.2.2.31. PacketTrap
Sitio Oficial: http://www.packettrap.com/
PacketTrap
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema que se distribuye bajo licencia comercial, se ajusta a las necesidades
del proyecto. En su sitio web cuenta con presentaciones del producto, cuenta con una
comunidad de usuarios que brinda apoyo para compartir información, realizar
preguntas, etc. Sobre el uso y funcionamiento del sistema.
3.2.2.32. Pandora FMS
Sitio Oficial: http://pandorafms.org/
PandoraFMS
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-.
-.
-.
-.
-.
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pandora Fms es un sistema que cumple con todos los requisitos básicos planteados
por nuestro cliente por consiguiente se puede considerar para ser elegido como
sistema candidato con posibilidades de ser un sistema finalista. Es un sistema que
cuenta con mucha documentación en español.
24
3.2.2.33. Performance CoPilot
Sitio Oficial: http://oss.sgi.com/projects/pcp/
Performance Co-Pilot
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Performance Co Pilot es un sistema pensado para realizar monitoreos on line a
sistemas con problemas de rendimientos, esta apto para recolectar métricas y
monitorear las áreas de: CPU, disco, memoria, la red, NFS, RPC, sistemas de
archivos. Es un sistema que no dispara alertas. Es un sistema apto para realizar
monitoreo centralizado de procesamiento distribuido.
3.2.2.34. Plixer Scrutinizer
Sitio Oficial: http://www.plixer.com
Plixer Scrutinizer
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Existen 2 productos distintos de Plixer Scrutinizer, un producto que se distriuye bajo
licencia comercial y otro de distribución libre. No es un sistema Open Source. Solo el
sistema que se adquiere bajo licencia comercial esta apto para generar monitoreos
con alarmas.
3.2.2.35. Polymon
Sitio Oficial: http://www.codeplex.com/polymon
Polymon
Atributo
(a)
(b)
(c)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
25
(d)
(e)
-
Cumple
No Cumple
Pagina Oficial
Pagina Oficial
PolyMon es un sistema de código abierto. Es un sistema de vigilancia que puede ser
utilizado para generar alertas por correo electrónico y analizar las tendencias históricas
y estados de contadores de monitoreo. Se basa en el. NET Framework 2.0 y SQL
Server 2005. Puede monitorear servicios Windows y administrarlos. No puede
monitorear plataformas distintas a Windows.
3.2.2.36. Server Eye
Sitio Oficial: http://www.server-eye.co.uk/en/
Server Eye
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Server eye es un servicio que se proporciona desde internet de monitoreo de sitios
web, monitoreo de servidores web y monitoreo de servidores desde distintos puntos
del mundo. Envía alertas de downtime vía SMS y correo electrónico, no es un software
que se adquiera e instale, es un servicio prestado por una compañía.
3.2.2.37. Seven Layer
Sitio Oficial: http://architel.com/integration-services/seven-layer/
Seven Layer
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
Comentario
No se indica en la pagina si
monitorea Sistemas Operativos que
no sean Windows
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
?
Pagina Oficial
No Cumple
Pagina Oficial
SevenLayer es un sistema de monitoreo, seguimiento de eventos, gestión del
conocimiento y generador de informes programado para utilizar Microsoft. NET
Framework. Se puede utilizar para controlar un solo sitio, una compleja aplicación
distribuida o una red empresarial. No se puede instalar en un ambiente que no sea
Windows.
26
3.2.2.38. SevOne
Sitio Oficial: http://www.sevone.com/
SevOne
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema de monitoreo comercial, se muestra en su sitio web como sistema de
última generación de gestión de redes de alto rendimiento que combina la máxima
funcionalidad en un formato fácil de administrar. Puede monitorizar distintos sistemas
operativos y componentes en la red. Cuenta con importantes clientes que utilizan el
sistema.
3.2.2.39. SNM
Sitio Oficial: http://snm.sourceforge.net/
SNM
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
No hay información
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
SNM significa System and Network Monitor , es un sistema Open Source que realiza
monitoreos de distintos sistemas operativos, servicios, aplicaciones y componentes de
red. Dispara alarmas cuando se llegan a determinados umbrales definidos y genera
notificaciones de las alarmas. En su página principal informa sobre el envío de correos
electrónicos informando sobre las alarmas generadas, pero no menciona la posibilidad
de envíos de mensajes SMS. No se hace referencia a usuarios que utilicen el sistema.
27
3.2.2.40. Solar Winds
Sitio Oficial: http://www.solarwinds.com/
Solar Winds
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Solar Winds es el nombre de la compañía que distribuye el producto Orion NPM. Este
es un producto que se distribuye bajo licencia comercial. Es una sistema que cumple
las funciones estándares de monitoreo.
3.2.2.41. Uptime Software
Sitio Oficial: http://www.uptimesoftware.com/
Uptime Software
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema de monitoreo comercial, que pude monitorizar distintos sistemas
operativos y componentes en la red. Cuenta con importantes clientes que utilizan el
sistema.
3.2.2.42. What’s up Gold
Sitio Oficial: http://www.whatsupgold.com/
What’s up Gold
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
What’s up gold es un sistema que se distribuye bajo licencia comercial, realiza
monitoreos, notifica, genera alertas y realiza presentación de informes de los distintos
componentes de la red.
28
3.2.2.43. Wormly
Sitio Oficial: http http://www.wormly.com/
Wormly
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Wormly es un sistema que se distribuye bajo licencia comercial, cuenta con una
versión trial disponible. No existe foro de ayuda, posee las características de
monitorear, alertar, reportar eventos que sucedan en la red.
3.2.2.44. Xymon
Sitio Oficial: http://www.xymon.com/
Xymon
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
No hay información
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
?
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Xymon es una herramienta open source para monitorizar servidores, aplicaciones y
redes. Recoge información sobre la salud de los computadores, las aplicaciones que
se ejecutan en ellas, y la conectividad entre los nodos de una red. Toda esta
información se presenta en una serie de páginas web intuitivas que se actualizan
frecuentemente para reflejar los cambios en el estado de los sistemas. En su página
oficial no identifica clientes que utilicen el software.
29
3.2.2.45. Z/OS RMF
Sitio Oficial: http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/
Z/OS RMF
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
RMF es un producto que se distribuye bajo licencia comercial de IBM, tiene como
características principales monitorear, registrar métricas de rendimiento y administrar
el sistema operativo Z OS.
3.2.2.46. Zabbix
Sitio Oficial: http://www.zabbix.org/
Zabbix
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Zabbix es un sistema open source que cumple con todos los requisitos que se buscan
del sistema a elegir. Es un sistema que tiene todo lo necesario como para ser elegido
como sistema finalista.
30
3.2.2.47. Zenoss
Sitio Oficial: http://www.zenoss.com/
Zenoss
Atributo
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
(o)
Comentario
-
Evaluación
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Cumple
Fuente
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Pagina Oficial
Zenoss es un sistema que cumple con todos los requisitos básicos planteados por
nuestro cliente por consiguiente pasa a ser un sistema candidato con posibilidades de
ser un sistema finalista.
3.2.2.48. Zyrion Traverse
Sitio Oficial: http://www.zyrion.com/?src=nocol
Zyrion Traverse
Atributo
(a)
(b)
Comentario
-
Evaluación
Cumple
No Cumple
Fuente
Pagina Oficial
Pagina Oficial
Es un sistema de monitoreo con licencia comercial. Es una solución que permite
detectar problemas en los componentes de la red y generar alertas ante estas
situaciones.
31
3.2.2.49.
Listado resumido de Sistemas
Del análisis de cada uno de los sistemas propuestos como candidatos se confecciona
la siguiente lista de sistemas que muestra en forma gráfica si se produce el
cumplimiento de las funcionalidades elegidas como básicas.
Nombre
(a)
(b)
(c)
(d)
(e)
(f)
(g)
(h)
(i)
(j)
(k)
(l)
(m)
(n)
Argus
Big Brother
CA eHealth
Cacti
CiscoWorks LMS
Collectd
dopplerVUE
entuity
everest
fireScope BSM
freeNATS
ganglia
GroundWork
Community
GroundWork
Enterprise
Heroix Longitude
Hyperic
Hyperic
Enterprise
Intellipool
Network Monitor
InterMapper
LoriotPro
ManageEngine
OpManager
Munin
Nagios
32
(o)
NeDi
NetCrunch
Nimsoft
Op5 Monitor
OpenNMS
Opsview
Osmius
PacketTrap
Pandora FMS
Performance CoPilot
Plixer Scrutinizer
Polymon
Server-Eye
Seven-Layer
SevOne
SNM
SolarWinds
Uptime Software
WhatsUpGold
Wormly
Xymon
z/OS RMF
Zabbix
Zenoss
Zyrion Traverse
33
3.3. Selección de los sistemas finalistas
Continuando con la metodología, se seleccionarán los siguientes sistemas finalistas en
base al cuadro de comparación de sistemas confeccionado en el punto anterior, y la
política de selección aplicada para eliminar sistemas, que consiste en corroborar que
todas las características que se identifican como imprescindibles (desde el numeral (a)
hasta el numeral (k)) deben cumplirse de forma obligatoria, si una de estas
características no es cumplida por el sistema se descartará de la lista. Luego de
reducida la lista a aquellos sistemas que cumplan con todas estas características, se
tendrán en cuenta también los numerales (l), (m), (n) y (o) para descartar sistemas.
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
Sistemas Pre Seleccionados
Estos sistemas fueron elegidos por cumplir con todos los requerimientos primarios
expuestos en la sección de Filtros Aplicados para eliminación de Sistemas. A
continuación, metodología BRR sugiere que de estos sistemas se elijan los 3 sistemas
finalistas para pasar a la próxima etapa, que consiste un compararlos entre si. Para
ello se investigan a fondo los sistemas seleccionados y nos basamos en las
descripciones de funcionalidades y en la documentación disponible de cada uno ellos
para realizar la selección.
Para esta etapa de investigación el grupo de proyecto se reparte los distintos sistemas
para analizarlos de forma mas profunda, tomando como base de análisis reglas
generales planteadas de antemano, para que cada sistema sea analizado desde un
punto de vista similar. En las posteriores reuniones de grupo de proyecto se discutirá y
elegirá cuales de estos 6 sistemas pasarán a la siguiente etapa.
Las normas generales establecidas para dicha etapa consistieron en investigar cada
sistema a fondo en cuanto a:
Pautas de Investigación
Opiniones de usuarios.
Clientes que utilizan los sistemas.
Existencia de quejas de usuarios.
Popularidad.
Documentación existente.
Funcionalidades extras.
Existencia de reportes generados.
34
Existencia de algún complemento que permita vincular las caídas de los
sistemas con los costos generados por esta causa.
Probar si es posible alguna demostración del sistema, observando
principalmente la facilidad de uso del mismo.
Alguna otra característica que haga que el sistema sea digno de implementar.
Ponerse en contacto con las distintas comunidades, para comprobar que grado
de apoyo brinda respecto al sistema.
Luego de analizar los sistemas en base a las aspectos expuestos en el punto anterior,
el grupo de proyecto se encontró con la situación que todos los sistemas tienen
características en principio que permiten que cualquiera de ellos este a un nivel
aceptable como para ser utilizado en el proyecto. Por consiguiente para realizar la
selección del sistema se tuvieron que ponderar determinadas características
otorgándoles un peso mayor que a otras. Las características elegidas fueron:
Caracterizas que definen la selección de sistemas finalistas
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.
Características de selección
Los sistemas finalistas elegidos fueron:

Hyperic HQ: se elige este sistema principalmente por tener reconocimientos a
nivel de premios como por ejemplo su versión Hyperic HP 3.1, según
Benchmark Capital (2007) [6], además parece ser un sistema muy estable y
completo.

Nagios: se elige este sistema porque es el líder indiscutible de mercado en
cuanto a reconocimiento, es uno de los sistemas mas usados y mas conocidos
de esta familia. A pesar de ello se encontraron críticas en cuanto al uso del
sistema. De todas formas es un sistema que cuenta con gran cantidad de
bibliografía disponible y reconocimiento.

Pandora FMS: es el sistema tal vez menos conocido de los tres, pero no por
ello menos atractivo para su uso. 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.
Luego de la selección de los sistemas finalistas el grupo de proyecto, realizará la
instalación de los mismos para corroborar su buen funcionamiento y se realizara un
testeo básico para corroborar que cumplen con los requerimientos básicos solicitados
por el cliente. Para esta etapa nuevamente se evaluarán los sistemas de forma
independiente, en donde cada integrante del grupo de proyecto trabajará con un
35
sistema específico. Además de la instalación de los sistemas se procede a realizar una
descripción más detallada de ellos que se expone a continuación en este documento.
:
3.4. Descripción de los sistemas finalistas
Se realizara un breve resumen de los 3 sistemas finalista para conocer más
características de ellos y tener una visión más amplia de los sistemas al momento de
la selección.
3.4.1. Hyperic HQ
3.4.1.1. Descripción general (funcionalidades y arquitectura)
Hyperic HQ es un software desarrollado para descubrir automáticamente y monitorear
Software y recursos de red. Provee una vista unificada de la situación de aplicaciones.
Cuenta con una serie de herramientas que permiten monitorear el rendimiento, crear
alertas, ejecutar diagnósticos y realizar acciones de control desde una consola remota.
3.4.1.2. Productos
Hay disponibles 2 versiones de Hyperic HQ.

Hyperic HQ 4.0: es una versión Open Source con licencia GNU GPL v2.

Hyperic HQ 4.0 Enterprise: esta versión esta disponible bajo licencia comercial,
tiene todas las capacidades de a versión Open Source, y además agrega
automatización y nuevas características de control.
3.4.1.3. Funcionalidades
Hyperic HQ monitorea y gestiona aplicaciones web a través de una amplia gama de
plataformas y tecnologías, provee de estas funciones básicas de gestión para recursos
de software o de red:

Descubrir: el agente HQ auto descubre los recursos de software y genera una
base de datos con información de los mismos. Dependiendo del tipo de
recurso es la información que guarda el agente. Por ejemplo obtiene
información de la arquitectura de una plataforma, por ejemplo: memoria RAM,
velocidad de la CPU, dirección IP etc. El agente utiliza paquetes propios de la
aplicación para auto descubrir sistemas operativos, servidores de aplicaciones,
servidores http, servidores de bases de datos y otras aplicaciones o recursos
36
de red. Además permite crear pluggins que gestionen recursos que el Hyperic
HQ no gestiona, o utilizar pluggins generados por la comunidad Hiperic con
estos fines.

Organizar: Los recursos que el agente descubre se guardan en la base de HQ
siguiendo el modelo jerárquico de base de datos3. Este modelo es fundamental
para permitir administrar una cantidad importante de recursos de Software y las
relaciones que se dan entre ellos.

Monitorear: el agente HQ colecta las métricas que reflejan disponibilidad,
rendimiento y utilización de sistemas. Los agentes obtienen un conjunto
estándar de métricas para cada tipo de recurso. Se pueden elegir que métricas
se van a monitorear desde la interfase web que provee la aplicación. Además
de métricas los agentes monitorean logs, eventos y cambios de configuración.

Controlar: Se puede utilizar HQ para realizar controles y administración remota
de los recursos de software. Los controles disponibles varían según el tipo de
recurso. Para servidores de aplicaciones se pueden realizar tareas como
comenzar y detener servicios, etc.

Alertar, notificar y escalar: se pueden configurar alertas sobre métricas
específicas y configurar acciones para que HQ ejecute cuando una alerta se
dispara. Cuando se dispara una alerta Hq puede responder de distintas
maneras: puede enviar notificaciones por correos electrónicos, establecer
trampas SNMP, o puede comunicarse con otros sistemas. Se debe definir que
respuestas ejecutara el HQ cuando se generen alertas.
Cuenta con un régimen de escalonamiento que permite resolver todos los
problemas.

Presentar, visualizar y analizar: La interfase web es altamente configurable y
esta hecha con portlets. Permite agregar, quitar y reorganizar estos portlets y
controlar que información se muestra.
3.4.1.4. Estructura
Hyperic esta compuesto por distintos componentes, que interactúan entre si para
provocar el funcionamiento de la aplicación. Estos componentes son: el Agente HQ, el
servidor HQ, la base de datos, la interfaz de usuarios, la HQ API, los plugg-in
3
El modelo jerárquico de bases de datos consiste en usar relaciones Padre-Hijo para relacionar los tipos
de registros. Esto se hace utilizando estructuras de tipo árbol. Solo puede existir un padre por hijo, y no es
posible crear relaciones entre registros hijos. Por Ejemplo: se vincula una universidad con un nodo, este
tiene estructuras hijas que representan departamentos, estudiantes y cursos. Se pueden tener varias
estructuras hijas de departamentos pero no se puede tener un funcionario que trabaje para mas de un
departamento. Para hacer esto tenemos que crear las instancias del mismo empleado en cada uno de los
departamentos que trabaja. Esta solución tiene como principal problema que puede generar
inconsistencias de datos al hacer actualizaciones ya que pueden existir datos repetidos en distintos
registros.
37
desarrollados para el sistema. También se expondrá sobre el inventario de HQ y el
modelo de acceso a datos.
.
3.4.1.4.1. Agente HQ
Se puede ejecutar un agente en cada máquina que desea administrar con Hyperic HQ.
El
agente autodescubre las aplicaciones que se ejecutan en la máquina y
periódicamente busca cambios de configuración, reúne métricas de disponibilidad,
utilización y rendimientos; realiza seguimientos de logs y eventos; permite realizar
acciones de control de software, por ejemplo, iniciar y detener servidores de
aplicaciones. El agente se encarga de enviar los datos que recoge al servidor central
de Hyperic HQ.
3.4.1.4.2. Servidor HQ y la base de datos
El servidor recibe los datos de los agentes y los almacena en la base de datos. El
servidor proporciona lo necesario para la gestión de su repositorio de software.
Implementa modelos de acceso, agrupando las aplicaciones de forma ordenada para
facilitar el proceso de supervisión y gestión. El servidor detecta las alertas cuando se
ejecutan y realiza las notificaciones definidas. Procesa las acciones que se inician
desde la interfaz de usuario o desde la API de servicios web de Hyperic. También
proporciona servicios de autenticación.
3.4.1.4.3. Interfaz de usuarios
Hyperic cuenta con una interfaz de usuario web. Desde esta aplicación permite tener
una visión general de los cambios en el inventario de software, visualizar problemas de
recursos, alertas, y métricas. Permite realizar la lógica del monitoreo y de las alertas.
3.4.1.4.4. HQ API
La API HQ es una API de servicios web que provee acceso programático a todas los
datos del servidor HQ y sus funcionalidades.
3.4.1.4.5. Complementos (Plugins)
Los plugins permiten ampliar las capacidades de Hyperic HQ. Existen dos tipos de
plugins:

El agente Hyperic utiliza plugins para descubrir, monitorear y controlar los
recursos de software. Hyperic tiene muchos plugins ya incorporados, y se
pueden construir otros para que los recursos sean compatibles con la
38
plataforma. La comunidad ha contribuido con una importante cantidad de
plugins que están también disponibles.

Se pueden construir plugins para extender la interfaz de usuario, desarrollar
scripts que permitan automatizar los procesos realizados más comúnmente y
desarrollar interfases de servicios web que interactúen con otros sistemas.
3.4.1.4.6. Inventario y modelo de acceso a datos
Cuando se habla de inventario se refiere a los recursos gestionados que componen la
infraestructura, se refiere a: equipos, sistemas operativos, servidores de aplicaciones,
aplicaciones, y otros componentes de software. Hyperic clasifica los recursos en base
a una jerarquía que son: plataforma, servidor y servicio. Una plataforma es un sistema
de hospedaje, un servidor es un producto de software que se ejecuta en una
plataforma, y un servicio es un componente que se ejecuta en un servidor, o está
asociado a una plataforma.
Hyperic auto-descubre plataformas, servidores y servicios. Hay también dos tipos de
recursos que puede configurar el usuario que son: las aplicaciones y los grupos.
Una aplicación es un conjunto de servicios que satisfacen a un conjunto de requisitos
de negocios.
Un grupo es un conjunto de recursos. Los grupos sirven para varios propósitos. Por
ejemplo, si se tiene un grupo de recursos del mismo tipo se puede realizar acciones de
control sobre ellos, como un reinicio a todos sus miembros utilizando un solo
comando. Los grupos también son fundamentales en el modelo de acceso, ya que los
recursos gestionados se agrupan por tener los mismos requerimientos de acceso.
Vinculando grupos y usuarios a roles que definen una serie de permisos, se puede
controlar a que recurso un usuario puede acceder y que acciones puede realizar sobre
ese recurso.
3.4.1.5. Requerimientos de Instalación
En esta sección se describirán los requerimientos de sistema y prerrequisitos para
instalar los componentes de Hyperic.
3.4.1.5.1. Servidor Hyperic
Se puede instalar un solo servidor en un equipo. Este equipo debe tener una dirección
IP estática.
39
3.4.1.5.1.1. Entorno en tiempo de ejecución Java (JRE)
El servidor puede correr con una JRE 1.5 ó 1.6. El fabricante recomienda utilizar una
JRE 1.5. Al momento de realizar este documento los paquetes de instalación de
Hyperic incluye una JRE 1.5. También existen paquetes de instalación que no incluyen
JRE.
3.4.1.5.1.2. Recursos para instalar el servidor Hyperic.
Para pequeños y medianos desarrollos, hasta 50 plataformas administradas se
requiere un equipo que contemple las siguientes características:
Recursos necesarios para instalar el servidor Hyperic
Como mínimo un procesador Pentium 4 de 1 GHz. , lo recomendado es 2 x 2.4
GHz Pentium Xeon o equivalente.
Como mínimo 1 GB. de memoria RAM, lo recomendado es 4 GB.
Como mínimo 1 GB. de espacio en libre en disco.
Recursos necesarios para instalar el servidor Hyperic.
3.4.1.5.1.3. Sistema Operativo
Es servidor Hyperic se puede instalar indistintamente en alguno de los siguientes
sistemas operativos: Linux, Solaris 10 o superior, Mac OS X (Intel x86) ó Windows
2003 Server.
Nota: Hyperic no soporta que su servidor se este ejecutando sobre Windows XP en un
ambiente de producción, pero si es posible efectuar desarrollos de evaluaciones sobre
Windows XP. Para la evaluación de este software se realizaron pruebas con el
Servidor Hyperic instalado en un Windows XP.
3.4.1.5.1.4. Librerías para plataformas basadas en UNIX
Para plataformas basadas en Unix, se requiere la instalación de la librería libXp.so.6 X.
La ubicación de esta biblioteca varía según sea la versión y proveedor:
40
3.4.1.5.2. Base de datos de Hyperic
3.4.1.5.2.1. Bases de datos que soporta el sistema
Hyperic instala por defecto una base de datos PostgreSQL V8.2.5, que es aconsejable
sólo para evaluación o para desarrollos muy pequeños. El sistema no soporta
desarrollos que usen esta base para ambientes de producción con más de 25
plataformas administradas.
Para ambientes de producción el fabricante recomienda instalar la base de datos en
una plataforma MySQL o Oracle, y que se localice en un equipo distinto al que está
instalado el Servidor de Hyperic.
Hyperic soporta el uso de estas bases de datos como base de datos externa:

MySQL: Versión 5.0.45 o superior. Hyperic no soporta la versión de MySQL
5.1.x al momento de realizar este documento.

Oracle: Versión 9 or 10 para Hyperic 4.0, o versión 10 o 11 para Hyperic 4.1 y
posteriores.

PostgreSQL: 8.3 o superior. Para esta base de datos se debe tener en cuenta
que Hyperic no soporta el uso de PostgreSQL ejecutándose en Windows en
entornos de producción.
El fabricante del sistema recomienda el uso de MySQL o Oracle en ambientes de
producción.
3.4.1.5.2.2. Hardware para la Base de datos
Los requerimientos necesarios para la instalación de la base de datos son los
siguientes:
Recursos necesarios para instalar la base de datos de Hyperic
Como mínimo un procesador Pentium 4 de 1 GHz., lo recomendado es 2 x 2.4
GHz Pentium Xeon o equivalente.
Como mínimo 2 GB. de memoria RAM (4 o más GB recomendados).
Como mínimo 10 GB de espacio libre en disco.
Hardware físico (no virtual).
Recursos necesarios para la instalación de la base de datos de Hyperic
41
3.4.1.5.3. Browsers soportados por el sistema
La interfase de usuario de Hyperic soporta los siguientes browsers: Firefox versiones
1.5.x o 2.0.x, Safari o Internet Explorer versiones 6 o 7.
El browser recomendado por el fabricante del sistema es Firefox.
3.4.1.5.4. Agente HQ
Se puede instalar un solo agente Hyperic por equipo. Este equipo debe tener una
dirección IP estática.
3.4.1.5.4.1. Recursos necesarios para instalar el agente HQ
Los requerimientos necesarios para la instalación los agentes de Hiperic son los
siguientes:
Recursos necesarios para instalar los agentes de Hyperic
Como mínimo un procesador de 500 MHz. Celaron, superior, o equivalente.
Como mínimo 256 MB de memoria RAM.
Como mínimo 500 MB espacio libre en disco.
Recursos necesarios para la instalación de los agentes de Hyperic
3.4.1.5.4.2. Sistema Operativo para instalar el agente
Los agentes de Hyperic se pueden instalar en los siguientes sistemas operativos:
Linux, Windows XP o 2003 Server, Solaris 8 o superior, Mac OS X, HP-UX 11.11 o
superior, AIX 5.2 o superior, y FreeBSD.
3.4.1.5.4.3. Entorno en tiempo de ejecución Java (JRE).
Los agentes de Hyperic pueden ejecutarse con una JRE 1.5 ó 1.6. El fabricante
recomienda utilizar una JRE 1.5. Al momento de realizar este documento los paquetes
de instalación de Hyperic incluyen una JRE 1.5. También existen paquetes de
instalación que no incluyen JRE.
3.4.1.6.
Instalación
En esta sección se exponen las instrucciones para instalar los componentes de
Hyperic usando el instalador.
42
3.4.1.6.1. El script de Instalación
El archivo de instalación, setup.bat para Windows o setup.sh para sistemas que no
son Windows, esta en el paquete de instalación de Hyperic HQ. Se puede instalar el
servidor, el agente o ambos.
Se pueden agregar parámetros de instalación que permiten configurar el modo de
instalación.
Argumento Descripción del modo de Instalación
Modo
Nada
Instalación rápida; los componentes HQ que se elijan para instalar se
instalarán con la configuración por defecto. Si se instala el servidor, se
configurará
para usar su base de datos built-in PostgreSQL.
Es la forma más sencilla de instalar HQ.
-full
Instalación completa; el instalador esperará se le suministren valores para
toda la instalación.
-upgrade
Actualización solo del server; el instalador espera se le ingrese el camino
del servidor para actualizarlo.
Instalación rápida cuando se va a utilizar una base de datos PostgreSQL
postgresql que no es la base por defecto (built-in); el instalador solicitará información
para conectarse a la base de datos y utiliza valores por defecto para el
resto de las configuraciones.
-oracle
Instalación rápida para Oracle; el instalador solicitará información para
conectarse a la base de datos y utiliza valores por defecto para el resto de
las configuraciones.
-mysql
Instalación rápida para MySQL; el instalador solicitará información para
conectarse a la base de datos y utiliza valores por defecto para el resto de
las configuraciones.
Parámetros de Instalación de Hyperic
3.4.1.6.2. Ejecutar el procedimiento de instalación
Se debe descomprimir el paquete de instalación. Dependiendo del modo de instalación
que se haya elegido el programa de instalación solicitará los valores que sean
necesarios para configurar el sistema. Si el proceso de instalación fue el correcto el
instalador provee la URL que lleva al portal de Hyperic. Por defecto esta URL es:
http://localhost:7080/
Para ingresar al sistema el usuario administrador es hqadmin y su contraseña es
hqadmin.
43
3.4.1.7.
Integración con otros sistemas
Hyperic permite a los desarrolladores personalizar, ampliar e integrar su solución en
base a sus necesidades a Hyperic, de forma de ajustar el sistema para su entorno.
Esto se puede realizar de 2 maneras. La primera es a través de desarrollos de plugins
de administración que permiten que Hyperic descubra, monitoree y controle cualquier
aplicación o dispositivo usando una simple API Java/XML. La otra forma es desarrollar
plugins que permitan crear componentes de interfase personalizados, que permitan
una integración con web services y la posibilidad de crear scripts de automatización
usando el lenguaje groovy.
3.4.2. Nagios
3.4.2.1. Características y funcionalidades
Nagios marca el estándar en la industria de monitoreo a grandes niveles por unas
cuantas razones. Este permite controlar la red informática y solucionar problemas
antes que los usuarios los detecten. Nagios es un sistema estable, escalable, con
soporte y extensible.
3.4.2.1.1. Monitoreo completo de la red
Este sistema permite monitorear una importante cantidad de dispositivos y sistemas
como por ejemplo: Sistemas Operativos Windows, Sistemas Operativos Linux/Unix,
Routers, Switches, Firewalls, Impresoras, Servicios y Aplicaciones.
3.4.2.1.2. Funcionalidades básicas
Se destacan las siguientes características de funcionamiento:

Enviar de forma inmediata notificaciones de problemas vía email, pager o
teléfonos celulares.

Capacidad de notificar a múltiples usuarios.

Uso de su interfase web que permite ver información detallada de los estados
de los distintos componentes, reconocer problemas de forma rápida.

Permite reiniciar automáticamente aplicaciones que hayan fallado, servicios y
equipos.
44

Permite agendar actualizaciones de hosts, servicios y componentes de la red.

Permite planificar las capacidades de los componentes a través del monitoreo.

Permite generar reportes de disponibiidad SLA (Service Level Agreements), y
reportes históricos de alertas y notificaciones. Además permite ver las
tendencias de los informes a través de la integración con Cactus y RRD.

Múltiples usuarios pueden acceder a la interfase web, además cada usuario
puede tener una vista única y restringida.
3.4.2.1.3. Arquitectura fácilmente extensible
NAgios cuenta con una muy importante cantidad de addons desarrollados por la
comunidad (más de 200) que permiten extender las funcionalidades del sistema.
3.4.2.1.4. Estable confiable y con una plataforma respetada
Nagios es un sistema que cuenta con más de 10 años en desarrollo, es un sistema
que permite escalar hasta monitorear más de 100,000 nodos, cuenta con gran
reconocimiento, ganador de múltiples premios. Actualmente cuenta con más de
250.000 usuarios alrededor del mundo. Tiene una lista de correos activa y una amplia
comunidad a través del website.
3.4.2.1.5. Código personalizable
Nagios es un software de código abierto, con acceso completo al código fuente,
liberado bajo licencia GPL.
3.4.2.2. Estructura
Según Domínguez Dorado Manuel; Zarandieta Morán Jose [2] Nagios tiene las
siguientes características principales en cuanto a su estructura:

El sistema cuenta con un núcleo que forma la lógica de control de negocio de
la aplicación, este contiene el software necesario para realizar la monitorización
de los servicios y de las máquinas de la red.
45

El sistema hace uso de diversos componentes que ya vienen en el paquete de
instalación con la aplicación, y puede hacer uso de otros componentes
realizados por terceras personas.

El autor sostiene que aunque permite la captura de paquetes SNMP para
notificar sucesos, pero no es un sistema de monitorización y gestión basado en
SNMP, sino que realiza su labor basándose en una gran cantidad de pequeños
módulos software que realizan chequeos de partes de la red.

Muestra los resultados de la monitorización y del uso de los diversos
componentes en una interfaz web a través de un conjunto de CGI’s y de un
conjunto de páginas HTML que vienen incorporadas, y que permiten al
administrador una completa visión de lo qué ocurre, en dónde ocurre y en
algunos casos el por qué ocurre.

Por último, si se compila para ello, Nagios guardará los históricos en una base
de datos para que al detener y reanudar el servicio de monitorización, todos los
datos sigan sin cambios.

Nagios permite monitorizar sistemas Windows mediante la instalación de un
agente en la máquina a monitorizar, aunque la parte servidor de Nagios debe
residir en un servidor Unix/Linux.
3.4.2.3. Requerimientos de instalación
Según Cayuqueo Sergio. (2009) [3], rara realizar una correcta instalación de Nagios,
con todas sus características es necesario tener instalados ciertos paquetes de
software en el sistema. La instalación puede variar según la distribución de Linux en
que se va a instalar, hay paquetes ya instalados y otros que hay que hacerlo
manualmente. A continuación se muestran los paquetes que deben estar instalados:
Paquete
Perl
Net::SNMP
Crypt::DES
RRDTool
Zlib
LibJPEG
LibPNG
Freetype2
Graphviz
Descripción
Interprete para el lenguaje descript
Perl
Modulo de Perl para consultas SNMP
Modulo de Perl para encripción DES,
necesario para consultas SNMPv3
Utilitario para generación de gráficas
de red y además su módulo de
integración con el lenguaje Perl
Librería de compresión utilizada por
las utilidades graficas
Librería para exportación jpg
Librería para exportación png
Librería para procesamiento de
fuentes
Utilitario para generación de gráficas
Sitio web
http://www.perl.org
http://search.cpan.org/dist/Net-SNMP
http://search.cpan.org/~dparis/CryptDES/
http://oss.oetiker.ch/rrdtool
http://www.gzip.org/zlib/
http://www.ijg.org/
http://www.libpng.org/pub/png/
http://www.freetype.org/
http://www.graphviz.org/
46
XFree86-libs
Apache 2
PHP
MySQL
Postfix
Librerías gráficas generales
Servidor Web
Interprete de lenguaje de script
Sistema de base de datos
SMTP para enviar mail
Librería para generación de formatos
GD
gráficos
Aditivo para la generación de
Nagvis
diagramas dinámicos
Aditivo gráficos estadísticos y
PNP4Nagios reportes para la generación de
visuales
Agregado para articular Nagios con
NDO
MySQL
Plugins de chequeo estándar de
Plugins
Nagios
Plugins para la integración de
SNMP Plugins
chequeos SNMP de Nagios
Nagios
Sitio de descarga oficial
Herramienta visual de configuración
NagiosQL
de Nagios via Web
http://koala.ilog.fr/lehors/xpm.html
http://httpd.apache.org/
http://www.php.net
http://www.mysql.com
http://www.postfix.org/
http://www.libgd.org/
http://www.nagvis.org/
http://www.pnp4nagios.org/
http://www.nagios.org
http://www.nagios.org
http://nagios.manubulon.com/
http://www.nagios.org
http://www.nagiosql.org/
Paquete necesario para el funcionamiento de NAGIOS según referencia 3
3.4.2.4. Instalación
Se debe de instalar un servidor y tantos clientes como nodos se deseen controlar. La
instalación del servidor se debe hacer en una plataforma Linux. Para los nodos no
existe una limitante respecto al sistema operativo. El proceso de instalación completo y
la configuración del sistema se encuentra en su sitio oficial.
3.4.3. Pandora FMS
En el manual de Pandora FMS 1.3.1 [4], se describe el sistema como “…una
herramienta de monitorización que puede cuantificar el estado (bien o mal) o
almacenar un valor numérico o alfanumérico en una base de datos por meses. Permite
medir rendimientos, comparar valores entre diferentes sistemas y establecer alertas
sobre umbrales…”.
Pandora FMS puede generar informes, estadísticas, niveles de adecuación de servicio
(SLA) y medir cualquier componente que proporcione o devuelva un dato. Es decir,
Pandora FMS puede medir: sistemas operativos, servidores, aplicaciones,
cortafuegos, proxies, bases de datos, servidores web, VPN, routers, switches,
procesos, servicios, acceso remoto a servidores, etc.
Todo esta integrado en una arquitectura abierta y distribuida y se puede implementar
sobre cualquier sistema operativo, con agentes específicos para cada plataforma.
Existen agentes para Windows (2000, XP, 2003), GNU/Linux, Solaris, HP-UX, BSD,
AIX, IPSO, y OpenWRT.
47
3.4.3.1. Características y funcionalidades
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 sistema a lo largo del tiempo. Otra característica
importante es que puede enviar SMS notificando alertas si un sistema falla.
Pandora FMS puede monitorizar cualquier proceso o sistema que mediante un
comando devuelva un valor, así como cualquier valor dentro de un registro de texto,
del sistema operativo, archivo de registro o similar.
3.4.3.1.1. Monitoreos mediante agentes
Algunos ejemplos de implementaciones de monitoreo mediante la utilización de
agentes pueden ser los siguientes:
Monitoreos Mediante el uso de Agentes
Número de conexiones (sesiones) de Checkpoint FW-1.
Número de sesiones de NAT de Checkpoint FW-1.
Número de conexiones del cortafuegos para GNU/Linux NetFilter/IPTables.
Número de paquetes registrados en FW-1.
Número de paquetes descartados en FW-1.
Número de paquetes aceptados en FW-1.
Estado de la alta disponibilidad de FW1 NG.
Ultima política instalada en un modulo de Firewall-1.
Estado de la sincronización de los módulos de FW1 NG.
CPU del sistema: idle, user y system.
Número de procesos del sistema.
Temperatura de la CPU de un sistema.
Valor de un registro Windows.
Procesos en cola de un dispatcher genérico.
Memoria del sistema: libre, swap, kernel FW-1, caché, etc.
Porcentaje de espacio libre en disco (por diferentes particiones).
Mensajes procesados por una puerta de enlace de correo.
Existencia de una cadena en un archivo de texto.
Tráfico por IP (filtrando según las conexiones del cortafuegos).
Visualizaciones de páginas en servidores HTTP (Apache, iPlanet, IIS, etc.).
Porcentaje de paquetes erróneos en una puerta de enlace.
Conexiones establecidas en un servidor de acceso remoto (RAS).
Tamaño de un fichero concreto.
Sesiones abiertas por un servidor VPN.
Rendimiento MySQL: Consultas e inserciones por segundo, nivel de caché
empleada, acierto de caché, consultas lentas, sesiones simultáneas,
Estado de sistemas Snort (eventos por segundo, estado de los sensores,
políticas cargadas, etc).
48
Eventos proporcionados por IDS (Snort) hasta seis niveles de prioridad o por
grupos.
Número de conexiones locales (TCP, UDP, sockets UNIX) y estadísticas
detalladas de la capa de red del S.O. (fragmentación de paquetes, pérdidas,
paquetes marcianos, y otros muchos tipos de anomalías detectadas por el
kernel).
Antivirus detectados por una pasarela Web Antivirus.
Tiempo de latencia ICMP hacia un equipo.
Tasa de transferencia media en una herramienta de transferencia de ficheros.
Numero de peticiones DNS atendidas por un servidor (incluyendo tipos).
Numero de sesiones FTP atendidas por un servidor FTP.
(Genérico) Estado de cualquier proceso/servicio activo en el sistema.
(Genérico) Estado de cualquier parámetro cuantificable del sistema.
Monitoreos a través de uso de Agentes
3.4.3.1.2. Monitoreos sin agentes (monitorización remota)
Algunos ejemplos de implementaciones de monitoreo remoto sin la utilización de
agentes pueden ser los siguientes:
Monitorización remota sin el uso de Agentes
Conocer si un sistema responde a PING (si está vivo o no).
Conocer el tiempo de latencia de un sistema (en milisegundos).
Saber si un puerto remoto TCP esta abierto o no.
Conocer el estado de un sistema remoto TCP en función de una respuesta a una
cadena enviada.
Por ejemplo, esto vale para saber si la versión SSH de un sistema remoto está
activo y no ha cambiado.
Esto también valdría para verificar que una pagina Web no ha sido alterada y
que responde bien.
Otra implementación válida sería simplemente para tomar un dato de una
aplicación Web.
Obtener información mediante SNMP.
Saber si un puerto remoto UDP responde.
Monitoreos remotos
3.4.3.2. Arquitectura
Pandora FMS es un sistema modular y descentralizado. Los distintos componentes del
sistema son: la consola, los servidores, la base de datos y los agentes.

Consola de Pandora FMS: Es la interfaz de usuario de Pandora FMS. La
consola de administración y operación permite a diferentes usuarios, con
diferentes privilegios: controlar el estado de los agentes, ver información
estadística, generar gráficas y tablas de datos así como gestionar incidencias
con su sistema integrado. También es capaz de generar informes y definir de
49
forma centralizada nuevos módulos, agentes, alertas y crear otros usuarios y
perfiles.

Servidores de Pandora FMS: En Pandora FMS 1.3.1 hay cuatro tipo de
servidores:
1. Servidor de datos: es el receptor de los paquetes de datos generados
por los agentes y el que los procesa.
2. Servidor de red: son quienes monitorizan sistemas remotos usando
recursos como ICMP, TCP, UDP o consultas SNMP. Los servidores de
red actúan sin necesidad de agentes y recogen toda la información de
forma remota.
3. Servidor Recon: explora las redes detectando nuevos sistemas en ella y
agregando los nuevos sistemas encontrados a Pandora FMS para que
pueda monitorizarlos de forma automática.
4. Consola SNNP: recibe y procesa traps SNMP, y lanza las alertas
asociadas a ellos.

Base de datos: La base central guarda toda la información que Pandora FMS
necesita para trabajar.

Agentes de Pandora FMS: recogen los datos del sistema. Se ejecutan en cada
sistema local. Los agentes de Pandora FMS han sido desarrollados de forma
diferente para cada plataforma específica, haciendo uso de las herramientas
propias del sistema anfitrión.
3.4.3.3. Requerimientos de instalación
Pandora FMS está compuesta por varios archivos shellscript (agentes UNIX/Linux), y
una aplicación Web en PHP (consola). Parte del código esta desarrollado en C++
(agente Windows), parte del código en PERL5 (servidor) y parte de la estructura y
bases de datos en SQL, por ello, para conseguir que todo esto funcione se necesita
tener algunas piezas de software en el sistema. Esta es una lista de paquetes,
bibliotecas y software que se necesita antes de instalar Pandora FMS.
3.4.3.3.1. Servidores
3.4.3.3.1.1. Servidor de datos de Pandora FMS
50
Para trabajar con el servidor de datos de Pandora FMS es necesario tener los
siguientes módulos de software Perl instalados en el sistema. Estos paquetes pueden
instalarse usando el sistema de distribución de paquetes de la distribución de
GNU/Linux o usando el sistema universal de paquetes Perl de CPAN.
Módulos PERL
XML Simple - Procesado y gestión de datos en formato XML.
Digest MD5 - Generación MD5.
Time - Manipulación básica y local de fecha y hora.
DBI, DB - interfaz con MySQL.
Date - Manipulación, gestión de formatos de fecha y hora.
Threads y threads shared - Pandora FMS puede trabajar en entornos multi-hilo y
emplea sistemas de memoria compartida para la comunicación entre procesos
(usando candados). Puede ser instalada recompilando el soporte para hilos en
Perl.
Módulos Perl necesarios para instalar el servidor de datos
Todas estas dependencias pueden ser encontradas en el sitio web de CPAN o
instaladas usando el sistema habitual de instalación de paquetes en la distribución
correspondiente. Estos paquetes están en la distribución de Suse 9.1 y Debian 3.0
GNU/Linux. También está disponible para Solaris en el repositorio de CPAN. Puede
que además sea necesario configurar la zona horaria (TZ) con sus correspondientes
variaciones.
3.4.3.3.1.2. Servidor de red de Pandora FMS
Requiere servidor SSH y Perl v5.8 o superior y los siguientes módulos Perl:
Módulos PERL
IO Socket - Empleo y manejo de los sockets TCP/UDP
Time HiRes - Se usarán tiempos ICMP
Time Local - Fecha y hora de manejo básico
SNMP - Para manejo de SNMP
Date - Necesidad de emplear formatos de fecha y hora con comparación de
entrada y salida
Net Ping - Para calcular tiempos de latencia (se requiere que el servidor funcione
como root)
Tthreads y threads shared - Manejo de Hilos de proceso
Módulos Perl necesarios para instalar el servidor de red

Se debe tener instalado el paquete NET-SNMP, incluido en todas las
distribuciones GNU/Linux. Se deberá emplear el binario snmptrapd que incluye
dicho paquete. Antes de instalarlo, se debe comprobar la configuración del
script lanzador para la consola de traps SNMP de Pandora FMS y asegúrese
de que la ubicación del snmptrapd binario es correcta en su distribución, que
suele ser /usr/sbin/snmptrapd. Esta ubicación se define con la variable
51
DAEMON_PATH. Este binario obtiene los traps SNMP, generando un registro
analizado por la consola SNMP de Pandora FMS.
3.4.3.3.1.3. Servidor de reconocimiento de red (recon)
El servidor de reconocimiento de redes de Pandora FMS, es una pequeña pieza
encargada de detectar sistemas mediante barridos ICMP. Para ello necesita algunas
dependencias de módulos Perl:
Módulos PERL
Socket, por defecto viene en la mayoría de distribuciones de Perl.
Posix, por defecto viene en la mayoría de distribuciones de Perl.
threads y threads shared - Por defecto viene en la mayoría de distribuciones de
Perl, excepto en algunos sistemas (Gentoo).
Net Ping - Por defecto viene en la mayoría de distribuciones de Perl.
Time Local - Por defecto viene en la mayoría de distribuciones de Perl.
NetAddr IP - Para gestionar direcciones IP, redes y máscaras de red. En las
versiones empaquetadas (RPM) de Pandora FMS, ya viene incluido. En algunos
sistemas como Debian o Ubuntu, también está como paquete .DEB. Se puede
instalar desde CPAN.
Módulos Perl necesarios para instalar el servidor de reconocimiento
A todos los efectos, la instalación con el instalador disponible en el repositorio de
código SVN o mediante alguno de los paquetes .rpm y/o .deb disponibles, conduce al
mismo resultado. La completa instalación automática del sistema, que nos deja en un
punto en el que sólo es necesario configurarlo para hacerlo funcionar. El instalador
está en el directorio de la rama de servidores de Pandora FMS, puede ejecutarlo sin
argumentos para ver su manejo.
3.4.3.3.2. Agentes
3.4.3.3.2.1. Agentes Unix
Los usos incorporados de las aplicaciones UNIX y sus herramientas harán que los
agentes que funcionen en este sistema sean muy sencillos. También existen agentes
desarrollados para AIX, GNU/Linux, Solaris y plataformas BSD, algunos de ellos muy
similares pero no idénticos. Para SUN Solaris y OpenSolaris, el paquete MD5 es
necesario para ejecutar correctamente el agente Solaris.
3.4.3.3.2.2. Agentes Windows
Para crear agentes de Pandora FMS desde el código fuente, se necesita la última
versión de Dev-Cpp IDE, con las herramientas MinGW. Se puede descargar desde
52
página web de Dev-Cpp. Para ello hay que Abrir el archivo PandoraService.dev con
Dev-Cpp y construya el proyecto. Todo debería compilarse bien en una instalación
normal.
3.4.3.4. Instalaciones
3.4.3.4.1. Instalación automática con el instalador
Es posible realizar una instalación completa y automática del sistema, que nos deja en
un punto en el que sólo es necesario configurarlo para hacerlo funcionar.
3.4.3.4.2. Instalación de la base de datos
En la nueva versión 1.3.1 de la consola Web de Pandora FMS el proceso de crear e
instalar la base de datos se puede hacer con facilidad con un navegador, siguiendo el
mismo asistente que instala y configura la consola.
3.4.3.4.3. Instalar la consola web
Antes de instalar la consola de Pandora FMS, se necesitan instalar las siguientes
dependencias y software:
Requerimientos para instalar la consola web
Servidor web. Se recomienda Apache2.
PHP 4.3.x o PHP 5.x. Se han probado ambos en Pandora FMS, pero se
recomienta la versión 5.x.
Los módulos PHP para MySQL, GD, gestión de sesiones y SNMP.
La biblioteca PEAR PHP.
Requerimientos para instalar la consola web
3.5. Puntuación de los sistemas finalistas
En esta sección del documento se realizará la selección del sistema mas apropiado al
proyecto, en base a las puntuaciones obtenidas aplicando la metodología BRR para
los sistemas finalistas y otros factores que el equipo de proyecto considere deban ser
tenidos en cuenta.
Para realizar la comparación se utilizará como guía el proceso descrito en el
documento BRR (2005) [5].
53
3.5.1. Ponderación de Categorías
La metodología sostiene que la inclusión de todas las categorías de evaluación es
contraproducente. Por consiguiente sugieren que los evaluadores realicen las
siguientes tareas:

Clasificación de la importancia de las categorías de la evaluación de uno a
doce (1-12) con respecto a la orientación funcional del software.

Decidir sobre un punto de corte en la lista de categorías de evaluación, o
sea se ordenan las categorías por orden de importancia y se elige un punto
en que la diferencia en importancia entre una categoría y la siguiente es
grande. Los evaluadores deben centrarse sólo en las categorías que están
por encima del punto de corte, y debe descartar e ignorar las otras. La
metodología sugiere que los evaluadores se centren en 7 o menos
categorías de evaluación.
3.5.2. Selección de los factores de ponderación adecuados
Una vez que los evaluadores han decidido cuales van a ser las 7 (o menos),
categorías de evaluación, deben concentrarse en el siguiente paso que es determinar
la cantidad en la que cada categoría debe contribuir al resultado final. Estos niveles de
contribución son los factores de ponderación, y están representados en porcentajes.
Todos los factores de ponderación en conjunto deben sumar el 100%. Para determinar
una buena distribución de los factores de ponderación, en el supuesto de que se
tengan 7 categorías de evaluación, la metodología sugiere que los evaluadores sigan
las siguientes pautas:






Ordenar las categorías en base a la importancia obtenidos en el paso anterior.
Asignar un factor de ponderación a la categoría que tiene el rango medio
(mitad de la lista ordenada).
Asignar ponderaciones a las categorías restantes. La metodología sugiere que
si un evaluador se centra en 7 categorías, la categoría que ocupa el cuarto
puesto inicial de obtener una ponderación del 15%, y en base a esto ponderar
las otras categorías.
A las categorías superiores en importancia en la lista (nivel de importancia 1, 2
ó 3), se le asignarían los coeficientes de 15% o más, y las categorías inferiores
en la lista (nivel de importancia 5, 6 ó 7) tendría coeficientes de 15% o menos.
Debe asegúrese que la suma de los pesos de las categorías a evaluar es de
100%.
Se podrán hacer ajustes finales si es necesario.
Ranking
1
2
3
4
Category
Funcionalidad
Calidad
Usabilidad
Rendimiento
Weight
25,00%
20,00%
20,00%
15,00%
54
Apoyo
10,00%
Comunidad
5,00%
Arquitectura
5,00%
Escalabilidad
0,00%
Seguridad
0,00%
Documentación 0,00%
Adopción
0,00%
Profesionalismo 0,00%
12
Figura : Categorías ponderadas por importancia
5
6
7
8
9
10
11
Las categorías fueron ordenadas según su importancia otorgada por el equipo de
proyecto ya que se espera del sistema que:

Cumpla con todas las funcionalidades que el cliente solicita

Se espera que responda de buena manera y asegurando cierto grado de
calidad en su accionar.

El sistema va a ser usado por personas de un centro de cómputos ajenas al
equipo de selección por este motivo es importante que posea una ciertas
características que lo haga amigable para los usuarios finales.

Se espera tener un rendimiento aceptable del sistema

Se espera contar con apoyo ante problemas, y el respaldo de poseer una
comunidad activa y dispuesta a ayudar a resolver inconvenientes.

Por último se considera que la arquitectura del sistema es importante,
fundamentalmente previendo posibles nuevos requerimientos y se vea
necesario utilizar complementos adicionales al sistema por ejemplo plugins.
3.5.3. Ponderación de Métricas por categorías
Las categorías tienen métricas asociadas, todas las mediciones dentro de una
categoría, ya sean cualitativos o cuantitativos, deben ser comparados con una escala
normalizada que permita realizar la medición y tenga sentido la comparación.
Para ello se utiliza una escala básica de 1 a 5 en donde los valores se podrían
relacionar de la siguiente manera:
55
Valor
1
2
3
4
5
Concepto
Inaceptable
Pobre
Aceptable
Muy Bueno
Excelente
No todas las métricas pueden alcanzar todos los valores, por ejemplo si es una
métrica es de tipo booleana (verdadero o falso), tiene 2 posibles valores. Una forma de
cuantificarla sería asignar el valor 1 si es falso ó el valor 5 si es verdadero. Existen
otras formas de cuantificar métricas en la documentación de la metodología en BRR.
(2005) [5].
Además del valor de la métrica, esta va a estar ponderada dentro de la categoría
teniendo un porcentaje de importancia asignado. La suma de todas las distintas
métricas dentro de la categoría deben sumar 100%.
Para este trabajo se utilizan las métricas recomendadas por la metodología para
realizar las comparaciones por categorías.
3.5.4. Métricas de Funcionalidad
Las métricas de funcionalidad de procesan de forma distinta a las métricas de las otras
categorías. Cada familia de sistema tiene un conjunto de características que deben ser
cumplidas por las aplicaciones que caigan en ese tipo, y además los sistemas pueden
incluir otras características adicionales que también deben ser tenidas en cuenta en el
momento de evaluar esta categoría. Se debe analizar que característica posee el
sistema y compararlas con un conjunto estándar de características de la familia de ese
sistema. Una vez obtenida la lista de características comunes a los sistemas la
metodología recomienda continuar de la siguiente manera:

Asignar una puntuación según la importancia de la característica a todas
aquellas que se encuentren en la lista de características comunes, usando una
escala de 1 a 3, en donde 1 indica que es de las menos importantes y 3 indica
que es de las mas importantes.

Comparar la lista de características del sistema contra la lista de estándares,
para cada característica del sistema encontrada en la lista estándar se debe
sumar la puntuación de importancia en una suma acumulativa. Las
características estándares que no sean cumplidas por el sistema se restaran
de la suma acumulativa.

Si el sistema tiene características extraordinarias (no se encuentra en la lista
de estándares), se debe asignar un grado de importancia a la misma y
agregarla a la suma acumulativa.
56

Luego de culminado el proceso para todas las características del sistema se
debe dividir el total obtenido sobre el máximo total posible de las características
estándares. Este índice es la puntuación de las características funcionales. Es
posible que sea mayor que 100% o menor que 0%, de esta manera se premia
el tener funciones extras y se castiga el no tener aquellas estándares.

Luego de obtener el porcentaje se debe comparar a la siguiente lista de
puntuación para obtener el puntaje de la categoría funcional.
Porcentaje Obtenido
Menos de 65 %
Entre 65 % y 80 %
Entre 80 % y 90 %
Entre 90 % y 96 %
Mayor que 96 %
Puntuación
1
2
3
4
5
Descripción
Inaceptable
Malo
Aceptable
Muy Bueno
Excelente
Cuadro X: de Puntuación de la Categoría Funcional.
A continuación se expone la lista de características estándares para la familia de
sistemas de monitoreo:
Lista de características estándares
Functionality group (General)
Monitorear distintos sistemas operativos
El servidor se instala en ambiente Linux
Monitorear al menos 15 componentes
Tener agentes de monitoreo que trabajan sobre los sistemas clientes
Generación de reportes operativos y estadísticos.
Tener una pantalla central de administración y configuración
Functionality group (hardware)
Monitorear hardware (uptime servers, routers, etc,)
Enviar Alarma si no responde el equipo (Server)
Enviar Alarma si no responde el equipo (router, switch)
Functionality group (Sistemas Operativos)
Enviar alarma si se llega a determinados umbrales de disco duro
Enviar alarma si se llega a determinados umbrales de memoria
Enviar alarma si se llega a determinados umbrales de CPU
Controlar procesos (cantidad)
Controlar archivos (tamaño)
Functionality group (Servicios y Aplicaciones)
Monitorear software de base y generar alarmas ante caídas
Monitorear software de aplicaciones y generar alarmas ante caídas
Functionality group (Notificaciones)
57
Permitir el envío de notificaciones vía email
Características estándares de los sistemas de monitoreo
3.5.5. Recolección de datos
Para poder cuantificar las categorías es necesario recoger información, para ello se
utilizará como principales fuentes: Internet y el contacto directo con los sistemas,
mediante su instalación y configuración.
3.5.6. Selección del sistema
Para obtener los resultados de la comparación de los sistemas se utilizan plantillas
Excel que están disponibles en el sitio de la metodología. Se genera una planilla por
sistema finalista, en éstas se cargan todos los datos referentes categorías y métricas.
A Continuación se expone un resumen de las mismas.
Métricas y puntajes referentes a la categoría Funcionalidades.
Funcionalidades Estándar
Ponderación Pandora Nagios Hyperic
Functionality group (General)
3
3
3
3
Monitorear distintos sitemas operativos
2
2
2
2
El servidor se instala en ambiente Linux
3
3
3
3
Monitorear al menos 15 componentes
Tener agentes de monitoreo que trabajan sobre
3
3
3
3
los sistemas clientes
2
2
2
2
Generación de reportes operativos y estadísticos.
Tener una pantalla central de administración y
2
2
2
-2
configuración
Functionality group (hardware)
Monitorear hardware (uptime servers, routers,
3
3
3
3
etc,)
Enviar Alarma si no responde el equipo (Server)
Enviar Alarma si no responde el equipo (router,
switch)
Functionality group (Sistmas Operativos)
Enviar alarma si se llega a determinados
umbrales de disco duro
Enviar alarma si se llega a determinados
umbrales de memoria
Enviar alarma si se llega a determinados
umbrales de CPU
Controlar procesos (cantidad)
Controlar archivos (tamaño)
Functionality group (Servicios y Aplicaciones)
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
3
2
2
2
2
2
2
2
2
58
Monitorear software de base y generar alarmas
ante caidas
Monitorear software de aplicaciones y generar
alarmas ante caidas
Functionality group (Notificaciones)
Permitir el envío de notificaciones via email
3
3
3
3
3
3
3
3
3
3
3
3
Cuadro de comparación de la categoría Funcional.
Categoría Calidad
Ponderación Pandora Nagios Hyperic
Cantidad de revisiones menores en los últimos 12
meses
Cantidad de revisiones no menores en los últimos
12 meses
5%
4
5
3
20%
5
1
3
Número de bugs abiertos en los últimos 6 meses
(desde 1/1/2009 hasta 30/6/2009)
15%
3
5
4
Número de errores corregidos en los últimos 6
meses (en comparación con el número de errores
abiertos)
20%
5
3
1
Cantidad de bugs criticos/P1 abiertos. (Se toman
como criticos errores de prioridad 9 en escala del
1 al 10),
20%
1
5
2
Promedio de tiempo en que se solucionan los
bugs criticos / P1 en los últimos 6 meses
20%
4
4
3
Cuadro de comparación de la categoría Calidad.
Métricas y puntajes referentes a la categoría Usabilidad.
Categoría Usabilidad
Experiencia con la interfaz de Usuario
Ponderación Pandora Nagios Hyperic
Tiempo para instalar prerequisitos previo a
instalar el sistema
Tiempo para la instalación terminada y
configurada
50%
5
3
3
25%
2
2
2
25%
2
2
3
Cuadro de comparación de la categoría Usabilidad.
59
Categoría Rendimiento
Ponderación Pandora Nagios Hyperic
Pruebas de rendimiento e informes de referencia
disponibles
50%
3
5
3
Ajuste de rendimiento y configuración, mide msi
hay alguna documentación o herramienta para
ayudar a afinar el componente en cuanto a
rendimiento y configuración.
50%
3
5
3
Cuadro de comparación de la categoría Rendimiento.
Categoría Apoyo
El volumen promedio de la lista de correo general
en los últimos 6 meses
Calidad de apoyo profesional
Respuesta ante consultas de usuarios
Ponderación Pandora Nagios Hyperic
25%
3
4
4
25%
50%
5
5
1
1
3
2
Cuadro de comparación de la categoría Apoyo.
Categoría Comunidad
El volumen promedio de la lista de correo general
en los últimos 6 meses
Número de contribuyentes código único en los
últimos 6 meses
Ponderación Pandora Nagios Hyperic
50%
3
4
4
50%
3
2
2
Cuadro de comparación de la categoría Comunidad.
Categoría Arquitectura
Existen plugins implementados por terceras
partes
Api Publica y servicios externos, mide si permite
realizar extensiones y personalizar el sistema
se puede configurar desde la aplicación
Ponderación Pandora Nagios Hyperic
35%
3
5
5
30%
3
5
5
35%
5
5
5
Cuadro de comparación de la categoría Arquitectura.
Luego de cargados los datos en las planillas se calculan los puntajes de cada sistema.
Los valores finales de los sistemas son los siguientes:
Sistema
Hyperic HQ
Nagios
Pandora FMS
Puntuación BRR
3,435
3,795
3,915
Puntuaciones Finales
60
Del análisis de los datos obtenidos en las planillas generadas para cada sistema se
llega a las siguientes conclusiones:

La categoría “Funcionalidad” fue la que el grupo de proyecto designo como de
mayor importancia, y en esta categoría los 3 sistemas finalistas lograron la
misma calificación (5 puntos), lo que corrobora lo expuesto en el capitulo 3.3 de
este documento en donde se exponía que los sistemas seleccionados eran de
características similares, y cualquiera de los 3 sistemas puede ser elegido en
cuanto al cumplimiento de los requisitos.

La diferencia entre los sistemas es menor y se da en algunas categorías, como
por ejemplo usabilidad que es la segunda categoría elegida en orden de
importancia. El sistema elegido cuenta con una interfaz de usuario amigable e
intuitiva, que permite desarrollar las tareas de administración y configuración
del mismo de forma relativamente sencilla.

Otra categoría importante es “Calidad” en la cual el sistema elegido esta con el
mejor puntaje (por muy poco margen), esto se da a pesar de que el sistema
elegido es el que mayor cantidad de errores reporta de los 3 sistemas, pero en
contrapartida es el que los soluciona de forma más rápida, y en mayor
porcentaje (79%).

En la otra categoría que el sistema elegido obtuvo un muy buena puntuación
fue en Soporte, y esto se debe básicamente a las respuestas obtenidas en
tiempo y forma por el grupo de proyecto en cuanto a inquietudes de
funcionamiento e instalación del sistema.
3.6. Pruebas básicas de funcionamiento de Pandora Fms.
Para corroborar que la elección realizada del sistema sea correcta se validan los
principales puntos expuestos en este documento, se plantean un conjunto de pruebas
básicas lo mas exigentes posibles dentro del ámbito de pruebas que esta al alcance
del equipo. Para ello se monta un laboratorio de pruebas en el cual se incorporan los
siguientes equipos: 1 computador personal, 2 computadores móviles (notebooks), 1
router.
Para realizar el conjunto de pruebas se contemplan los requerimientos planteados por
el cliente y mencionados en el capitulo 3.1 de este documento. Para ello se preparan
los equipos por lo que se realizan las siguientes tareas:

Se instala un sistema Linux en un notebook con el servidor del sistema
Pandora Fms versión XXXX.
61

Se instala un sistema Linux y el agente para Linux de Pandora en un
computador con un servidor apache. Si se puede hacer Lo mejor es una VPN

Se instala el agente para Windows de Pandora y el ISS en el otro computador.

El equipo que tiene instalado el servidor de Pandora Fms realiza el rol de
servidor de Pandora.

Los equipos en los que se instalo el cliente desarrollan el papel de servidores
de aplicaciones.

Se configura una red de datos con los 3 computadores y el router.
En las pruebas realizadas en el laboratorio se configura el sistema para que dispare
alarmas cuando detecta caído algún elemento monitoreado. De esta manera se
perseguía el fin de corroborar el buen funcionamiento de la aplicación en lo referente a
los siguientes items:

Corroborar que el sistema detecta cuando un servidor de aplicaciones queda
off line. Las pruebas se realizan para los 2 servidores de aplicaciones (Linux y
Windows).

Corroborar que el sistema detecta cuado un servicio queda off-line,
persiguiendo este fin se configura el sistema para que dispare alarmas cuando
los servicios apache (en Linux) o ISS (en Windows) se detienen.

Corroborar que el sistema monitorea de forma correcta el uso de memoria,
disco y CPU para los sistemas clientes. Se configuran alarmas para que se
disparen cuando se llega aun determinado umbral.

Corroborar que el sistema detecta la caída de un router, para ellos se configura
que se dispare una alarma cuando este no responde.
De las pruebas realizadas se obtiene como resultado el buen funcionamiento del
sistema, corroborando que se detectan los problemas que el cliente plantea como
básicos en sus requerimientos.
62
Anexo 1
Sitios oficiales de las aplicaciones analizadas en este trabajo
Nombre
Argus
CA eHealth
Cacti
CiscoWorks
LMS
Collectd
dopplerVUE
entuity
everest
fireScope BSM
freeNATS
ganglia
GroundWork
Community
GroundWork
Enterprise
Heroix
Longitude
Hyperic
Intellipool
Network
Monitor
InterMapper
LoriotPro
ManageEngine
OpManager
Munin
Nagios
NeDi
NetCrunch
Nimsoft
Op5 Monitor
OpenNMS
Opsview
Osmius
PacketTrap
Pandora FMS
Performance
Co-Pilot
Plixer
Scrutinizer
Polymon
Server-Eye
Seven-Layer
SevOne
SNM
URL
http://argus.tcp4me.com/
http://www.ca.com/us/network-performance.aspx
http://www.cacti.net/
http://www.cisco.com/en/US/products/sw/cscowork/ps2425/index.html
http://collectd.org/
http://www.dopplervue.com/
http://www.entuity.com/
http://www.lavalys.com/
http://www.firescope.com/Products/BSM/
http://www.purplepixie.org/freenats/
http://ganglia.info/
http://www.groundworkopensource.com/community/
http://www.groundworkopensource.com/products/enterprise/
http://www.heroix.com/
www.hyperic.com
http://www.intellipool.se/
http://www.intermapper.com/
http://www.loriotpro.com/
http://www.manageengine.com/products/opmanager/
http://munin.projects.linpro.no/
http://www.nagios.org/
http://www.nedi.ch/
http://www.adremsoft.com/netcrunch/
http://www.nimsoft.com/
http://www.op5.se/nyheter/201-op5-releases-new-version-of-op5monitorhttp://www.opennms.org/index.php/Main_Page
http://www.opsview.org/
http://www.osmius.net/es/
http://www.packettrap.com/
http://pandorafms.org/
http://oss.sgi.com/projects/pcp/
http://www.plixer.com
http://www.codeplex.com/polymon
http://www.server-eye.co.uk/en/
http://architel.com/integration-services/seven-layer/
http://www.sevone.com/
http://snm.sourceforge.net/
63
SolarWinds
Uptime
Software
WhatsUpGold
Wormly
Xymon
z/OS RMF
Zabbix
Zenoss
Zyrion
Traverse
http://www.solarwinds.com/
http://www.uptimesoftware.com/
http://www.whatsupgold.com/
http://www.wormly.com/
http://www.xymon.com/
http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/
http://www.zabbix.org/
http://www.zenoss.com/
http://www.zyrion.com/?src=nocol
64
Referencias
Ref 6
[1] - Chris Knowles. 2007. The Truth about Agent vs. Agentless Monitoring A Short
Guide to Choosing the Right Solution. Disponible en internet:
http://searchcio.bitpipe.com/detail/RES/1217246735_716.html
[2] - Domínguez Dorado Manuel; Zarandieta Morán Jose.2003. Evaluacion de Nagios
para Linux. Disponible en internet:
http://nagios.sourceforge.net/download/contrib/documentation/misc/Nagios_spanish.pdf
[3] - Cayuqueo Sergio. 2009. Monitoreo y análisis de Red con Nagios. Disponible en
internet: http://cayu.com.ar/files/manual-nagios-2009.pdf
[4] - Pandora FMS.2008. Documentación de usuario Pandora FMS 1.3.1
Disponible en internet: http://pandorafms.org/
[5] - BRR. 2005. Business Readiness Rating for Open Source(A Proposed Open
Standard to Facilitate Assessment and Adoption of Open Source Software ).
Disponible en Internet: <http://www.openbrr.org/wiki/index.php/Downloads
[6] – Benchmark Capital. 2007. Hyperic Wins Best Systems Management Tool Award
at LinuxWorld. Disponible en Internet:
<http://www.benchmarkcapital.com/news/sv/2007/08_08_2007b.php>
http://support.hyperic.com/display/hypcomm/HyperFORGE
Metricas Hyperic
http://forums.hyperic.com/jiveforums/index.jspa?categoryID=1
Metricas Hyperic
http://support.hyperic.com/display/DOC/HQ+Documentation
Documentación Hyperic para la descripción
http://sourceforge.net/tracker/?atid=397597&group_id=29880&func=browse
Metricas NAgios
http://sourceforge.net/tracker/?group_id=155200&atid=794852
Metricas Pandora FMS
65