Proyectos Multidisciplinares de las TIC-II.

Mster en Telecomunicacin 2012-2013.

Autor: Julio Jornet Monteverde.

ndice de contenido.
1.

INTRODUCCIN. ............................................................................................................................ 3
1.1.
SISTEMAS DE MONITOREO CON O SIN AGENTES .......................................................................................... 3

2.

EL PROYECTO OPENNMS................................................................................................................. 5

3.

FUNCIONALIDADES ........................................................................................................................ 6
3.1.
GESTIN DE EVENTOS Y ALARMAS ........................................................................................................... 6
3.1.1.
Recoleccin de Eventos ............................................................................................................ 6
3.1.2.
Correlacin de Alarmas ........................................................................................................... 7
3.1.3.
Notificaciones de Usuario y Escalados Programados .............................................................. 9
3.1.4.
Integracin de Trouble Tickets ................................................................................................. 9
3.2.
RENDIMIENTO Y GESTIN DE SLAS ........................................................................................................ 10
3.2.1.
Rendimiento y Gestin de recoleccin de datos .................................................................... 10
3.2.2.
Visualizacin de Datos ........................................................................................................... 10
3.2.3.
Gestin de SLAs ..................................................................................................................... 11
3.3.
INTEGRACIN Y GESTIN DE CONFIGURACIN ......................................................................................... 11
3.3.1.
Configuracin unificada ........................................................................................................ 11
3.3.2.
Descubrimiento de la Red ...................................................................................................... 12
3.3.3.
Configuracin de Interfaces ................................................................................................... 13
3.3.4.
Integracin............................................................................................................................. 14
3.4.
POLLER REMOTO ................................................................................................................................ 15

4.

ARQUITECTURA ........................................................................................................................... 15
4.1.
MEJORAS VERSIN 2.0. ....................................................................................................................... 16

5.

IMPLEMENTACIN EN SPED.......................................................................................................... 17

6.

OTROS SISTEMAS DE GESTIN DE RED .......................................................................................... 19

6.1.
NAGIOS ............................................................................................................................................. 19
6.1.1.
Caractersticas y funcionalidades .......................................................................................... 20
6.1.2.
Funcionalidades bsicas ........................................................................................................ 20
6.1.3.
Estructura .............................................................................................................................. 21

7.

BIBLIOGRAFA Y REFERENCIAS ...................................................................................................... 22

1. Introduccin.
OpenNMS es una de las alternativas libres ms destacadas para realizar tareas de
administracin y gestin de redes, bajo sistemas Linux. Esta poderosa herramienta,
incorpora un paquete de funciones, que permiten controlar por completo todo el trfico de
datos que se transmite a travs de la red. OpenNMS es una aplicacin fcil de utilizar.
Podemos manipular cada una de las caractersticas de la red, as como, analizar y detallar
cada uno de los archivos que se transfieren, y realizar una serie de tareas de gestin y de
conexiones de red.
Este software realiza un anlisis de cada una de las conexiones entrantes y salientes de
nuestra red, con el principal objetivo de verificar si existen conexiones no autorizadas.
Tambin, genera reportes completos de gestin, para documentar cada una de las
situaciones que se presenten en la red. Cuenta con una licencia de funcionamiento GPL.
OpenNMS es una plataforma de gestin de red de nivel empresarial desarrollada en el
marco del modelo de cdigo abierto. A diferencia de los productos de gestin de red que
estn muy centrados en los elementos de red tales como los interfaces switches y routers,
OpenNMS se centra en los recursos de red que ofrecen servicios: pginas web, acceso a
bases de datos, DNS, DHCP, etc (aunque la informacin sobre elementos de la red
tambin est disponible ).

Como la mayora de los servicios de red se proporcionan a travs del protocolo TCP / IP,
OpenNMS est muy centrado en el nivel IP. El elemento bsico de monitorizacin se
llama "interfaz", y una interfaz se identifica por una direccin IP. Los servicios se asignan
a las interfaces, y si una serie de interfaces que se descubren pertenecen al mismo
dispositivo (ya sea a travs de SNMP o SMB), stas pueden agruparse juntas en un
"nodo".

1.1. Sistemas de monitoreo con o sin agentes

El agente de un sistema de monitoreo es un componente de software. Generalmente es
una pequea aplicacin que reside en el cliente y recoge datos. Los datos se envan al
servidor central de la aplicacin en base a 2 opciones. La primera opcin es que el envo
de datos sea administrado por el agente local, o este sea administrado por la estacin de
3

monitoreo central.

Los sistemas que tienen la poltica de envo de informacin 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 polticas de envo de
informacin 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.

Sistemas con agentes

Ventajas

Desventajas

Ventajas

Desventajas

Informacin ms especfica y ms detallada.

Mayor
flexibilidad
para
realizar
monitoreos
personalizable.
Posibilidad de crear soluciones de monitoreos que
controlen estados de servicios o mtricas no
estndares 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 encriptacin.
Menor riesgo de deteccin de inactividades.
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 opcin para casos en los que no es posible
instalar aplicaciones en los clientes
Tiene mtricas menos especificas por consiguiente
se pueden realizar anlisis menos detallados.
Pueden ser afectadas por hechos que sucedan en la
red.
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.

Las soluciones basadas en agentes instalados en el cliente brindarn acceso a ms

informacin y con mtricas ms detalladas, este hecho puede ser importante para
disminuir el tiempo de deteccin de fallos, mientras que soluciones sin agentes le
permiten al fabricante evitar la etapa de desarrollo del agente pero con el riesgo de
4

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 caracterstica de tener en su estructura el
uso de un agente en el cliente.

2. El Proyecto OpenNMS
Como ya se ha comentado, OpenNMS es un sistema de gestin de red orientado a
agente, y es la primera plataforma desarrollada bajo cdigo abierto, GPL.

Est escrito en Java y por lo tanto es portable a todas las plataformas del mercado,
Windows, Linux, Sun, Unix, etc. Su escalabilidad en los sistemas ha sido probada, prueba
de ello son los resultados obtenidos: 300.000 puntos de datos cada 5 minutos y deteccin
automtica de nodos centrales con ms de 5000 interfaces.

Existe una amplia comunidad de usuarios comerciales que utilizan OpenNMS en sus
sistemas, tales como: Swisscom, MySpace, Foxtel, Fox TV, BBC Monitoring, Wind
Telecomunications.
La comunidad OpenNMS es muy activa y existen cerca de 1000 usuarios activos
subscritos en las listas de discusin. En la actualidad tienen unos 35 desarrolladores con
acceso a los repositorios. La comunidad est gestionada por la Orden del Polo Verde
(OGP). Todos los miembros de dicha orden tienen un voto en la direccin del proyecto y
5

no existen restricciones de acceso.

La licencia es del tipo GPL y la propiedad intelectual as como la marca es propiedad del
Grupo OpenNMS. El objetivo del grupo es promover el proyecto.

3. Funcionalidades
OpenNMS est dividido en una serie de funcionalidades que cumplen con unas
determinadas caractersticas.

3.1. Gestin de Eventos y Alarmas

3.1.1. Recoleccin de Eventos
OpenNMS puede registrar todo tipo de eventos ocurridos: Trigers, evaluacin de eventos,
automatizacin de acciones en funcin del procesado de la tabla de alarmas.
Los Nodos Pasivos se utilizan para representar servicios o recursos gestionados por otro
agente. Existen dos procesos llamados Event Translator y Pasive Status que permiten a
los eventos mapearse a estos nodos.
El proceso Actiond se utiliza para generar acciones Java basados en la recepcin de
eventos. Tambin se pueden enviar los eventos que se deseen via XML-RPC a otro
sistema de gestin remoto.

Los eventos se controlan con el proceso Eventd el cual recibe y graba toda la informacin.
Este proceso escucha el puerto 5817 por el cual los dems procesos envan peticiones e
incluso se pueden enviar desde sistemas externos a OpenNMS.

Listado de Eventos

3.1.2. Correlacin de Alarmas

Se utiliza un mecanismo de Alarma para manejar traps de recoleccin de alarmas o traps
de anulacin de alarmas en un entorno de gestin de alarmas cclico. Cuando se recibe
7

por primera vez un trap o disparo se recoge una alarma. Si se reciben sucesivos traps,
stos se contarn en la misma alarma. Si se reconoce la alarma, se provocar un trap de
limpieza de la alarma y sta desaparecer quedando el sistema preparado para recibir un
nuevo evento. Este mecanismo de utilizacin es el ms simple en un listado de alarmas.
El usuario tambin puede configurar reglas ms sofisticadas de tratamiento de eventos de
alarmas incluso automatizndolo en funcin de un sofisticado anlisis ya que posee un
motor de reglas.

Listado de Alarmas

Detalle de Alarma

3.1.3. Notificaciones de Usuario y Escalados Programados

OpenNMS soporta mltiples usuarios y proporciona un mecanismo de Escalado de
Notificaciones entre los usuarios. Si se detecta un evento severo, como una alarma
Mayor, este mecanismo generar una Notificacin que se escalar en el tiempo a travs
de una lista de usuarios si la alarma no se reconoce en un periodo de tiempo definido por
el usuario. El sistema tambin puede generar un sonido, un email o un mensaje
instantneo para llamar la atencin sobre la notificacin. Tambin existen mecanismos de
notificacin tales:
-

XMPP: Jabber, un protocolo de mensajera instantnea.

Programas externos

Traps SNMPs

HTTP GET/POST hacia una web site.

Se pueden definir grupos de usuarios y roles a los cuales se les puede asociar cuentas
email genricas.

Listado de Notificaciones

3.1.4. Integracin de Trouble Tickets

Si el mecanismo de escalado bsico no es suficiente, OpenNMS tambin dispone de una
interface Trouble Ticket para integrarlo en el sistema con un nmero de incidencia.

3.2. Rendimiento y Gestin de SLAs

3.2.1. Rendimiento y Gestin de recoleccin de datos
Como en otras herramientas de gestin de redes tales como Nagios o Cricket, OpenNMS
almacena datos en ficheros RRD. Se puede utilizar la herramienta RRD para hacer la
recoleccin de datos pero la librera preferida es JRobin la cual es una implementacin
Java de RRD.
OpenNMS ya lleva implementada una MIBS (base de datos SMNP) que soporta la gran
mayora de fabricantes de equipamiento, pero los usuarios pueden definir sus propias
configuraciones. La comunidad de usuarios suelen compartir estos trabajos y sus
experiencias con los nuevos equipos.
Sin embargo, a diferencia de estas herramientas, toda la programacin de la recoleccin
de datos se controla totalmente por un proceso Java dentro de OpenNMS el cual hace
que la solucin sea muy escalable.
Los datos pueden recogerse desde varias fuentes distintas: sondeo SNMP, traps de
gestin, mensajes ASCII tipo syslog, TL1, JMX. Tambin existe una integracin con
Nagios que permite la utilizacin de plugins de Nagios. OpenNMS tambin se ha
integrado con SNORT.

3.2.2. Visualizacin de Datos

OpenNMS presenta los datos de rendimiento en forma de grficos. Estos grficos tambin
se pueden exportar en forma de informes de rendimiento.
Tambin se pueden definir umbrales que generan alarmas cuando hay cambios en los
datos. OpenNMS puede realizar transacciones sintticas para comprobar la disponibilidad
de servicios en los nodos. Esto se puede realizar de una manera centralizada o con un
conjunto de rollers distribuidos remotamente.

10

3.2.3. Gestin de SLAs

Se pueden definir umbrales en los SLAs que generarn una alarma en cuanto se rebasen
y pueden escalarse en funcin de las reglas definidas. A cada punto de recoleccin de
datos de rendimiento se le puede asignar dos umbrales, uo superior y otro inferior, para
evitar los rebotes de alarmas.

3.3. Integracin y Gestin de Configuracin

3.3.1. Configuracin unificada
Toda la configuracin de OpenNMS est almacenada en archivos XML y se encuentra
dentro de un directorio. Muchas de estas configuraciones tambin se exponen en la
interface de usuario. Las configuraciones incluyen los tiempos de barrido, mapeado de
traps del tipo eventos/alarmas, gestin de MIBs, etc.

11

3.3.2. Descubrimiento de la Red

Dado un rango de direcciones, OpenNMS puede descubrir por si mismo los elementos y
servicios dentro de una red. Automticamente asocia puertos con nodos. La nomenclatura
por defecto de un nodo en la base de datos se rellenar con el nombre del dispositivo
detectado por un escaneo SNMP del dispositivo.
El proceso responsable de la tarea de detectar los servicios es Capsd y es capaz de
detectar los siguientes servicios:
-

Citrix
DHCP
DNS
Domino IIOP
FTP
General Purpose (script based)
HTTP
HTTPS
ICMP
IMAP
JBOSS (JMX)
JDBC
JDBC Stored Procedure
JSR160
K5
LDAP
Microsoft Exchange
MX4J
Notes HTTP
NSClient (Nagios Agent)
NRPE (Nagios Remote Plugin Executor)
NTP
POP3
Radius
SMB
SMTP
SNMP
SSH
TCP
Windows Services (SNMP-based)

Es posible importar la configuracin de los servicios con un fichero tipo XML. Esta
configuracin deshabilitar los procesos de descubrimiento por medio de barridos ping. El
proceso Capsd es el responsable de descubrir todos los servicios a monitorizar sobre un
dispositivo. Recopila y almacena datos de diversas fuentes, incluyendo SNMP, JMX,
HTTP y NSClient.
Si el dispositivo tiene implementado SMNP, entonces es capaz de manejar todos los

12

servicios interrogando y registrando los tiempos de respuesta utilizando transacciones

sintticas.

3.3.3. Configuracin de Interfaces

Tambin se pueden utilizar archivos XML conteniendo la configuracin de las interfaces y
as modificar el nombre y el inventario de la Red. Como ejemplo podemos comentar que
esta interfaz la utiliza Swisscom para sincronizar OpenNMS con su red WIFI Europea de
Hotspots.
OpenNMS implementa un mecanismo de provisionamiento automtico que est integrado
con el sistema RANCID (RANCID Really Awesome New Cisco confIg Differ
http://www.shrubbery.net/rancid/),

tambin

(http://reductivelabs.com/trac/puppet).

Ejemplo de Porvisionamiento Manual

Ejemplo de Provisionamiento externo con XML

13

con

PUPPET.

3.3.4. Integracin
OpenNMS posee numerosos puntos de integracin para la paginacin, sonidos de
alarmas, email, tratamiento de tickets/incidencias, etc.

El sistema est preparado para utilizar mapas para mostrar la topologa de la red tal y
como se refleja a continuacin.

14

3.4. Poller Remoto

OpenNMS implementa una funcionalidad para poder realizar interrogaciones desde
puestos remotos. El cliente remoto se conecta al servidor OpenNMS y se descarga el
plugin Remote Poller utilizando el Java Web Start. Una vez ejecutndose, el plugin
interroga los servicios de los nodos centrales utilizando transacciones sintticas. Una vez
se tienen los resultados, se envan al servidor OpenNMS.

4. Arquitectura
A continuacin se muestra un diagrama de bloques de la arquitectura OpenNMS:

15

El sistema tiene una serie de APIs que son las siguientes:

API Servicio Detector: Deteccin de Servicios, Interface Java.

API Servicio Monitor: Plugin Poller para monitorizar los servicios detectados,
Interface Java.

API Servicio Recoleccin: Plugin Collectd para crear los recolectores de datos de
rendimiento. Interface Java.

API Servicio Thesholder: Plugin para crear umbrales de servicios detectados.

Interface Java.

API Notificaciones estratgicas: Plugin para crear nuevos mtodos de notificacin.

Interface Java.

API Reconocimiento: Plugin para leer las respuestas a las notificaciones. Interface
Java.

API Provisin Adaptador: Plugin para la integracin de CMS, EMS, sistemas de

inventariado, etc. Interface Java.

A continuacin se muestra un ejemplo de cmo se comunican los procesos internos:

4.1. Mejoras versin 2.0.

-

En la parte de provisionamiento se ha implementado una nueva arquitectura con un

modo de descubrimiento de servicios y recursos en paralelo.

La interfaz de usuario se ha actualizado a un entorno Web (AJAX)

16

Se ha mejorado el flujo de trabajo de las Alarmas y del Escalado.

Se ha implementado una API REST para poder acceder utilizando tecnologas web
(Pearl, python, etc).

Se han implementado seguridad en las Listas de Control de Acceso a Usuarios

(ACLs) permitiendo una granularidad fina del control de usuarios.

Tambin se han reducido el nmero de reinicios requeridos en el sistema por

cambios en la configuracin.

Se ha implementado un mdulo de soluciones de tolerancia a fallos.

5. Implementacin en SPED
Tal y como se ha planteado el Sistema de Prevencin, Extincin de incendios forestales y
Deteccin de plantaciones irregulares (SPED), y una vez analizado en profundidad el
funcionamiento del sistema OpenNMS, podemos implementarlo para controlar y gestionar
nuestros servidores de datos, servidores de grabacin de imgenes y hasta en nuestros
dispositivos concentradores o routers Meshlium Xtreme ya que tienen un SO basado en
Linux y por lo tanto podemos cargar el agente OpenNMS.
El hecho de que podamos implementar OpenNMS en los routers Meshlium tambin
implica que podamos supervisar las interfaces de ste y por ello nuestra red de
transmisin compuesta de enlaces punto-punto o punto-multipunto.
En cuanto a los Motes, no podemos utilizar el sistema OpenNMS ya que estos
dispositivos estn configurados para utilizar la tecnologa ZigBee como medio de
comunicacin hasta el router y todava no est soportado Zigbee en OpenNMS. Adems,
existe una restriccin que hace que los Motes no puedan implementar un agente y es que
el software de control est especialmente diseado para tener un bajo consumo. Esto
conlleva a que el Mote est la mayor parte del tiempo en modo suspensin y solamente
se despierte para enviar los valores de los sensores y para notificar al coordinador de su
existencia. Tambin tenemos la limitacin de la memoria ya que estos dispositivos tienen
muy poca memoria.
Existe un modelo de Mote que implementa un interface WIFI para la comunicacin y que
nos permitira gestionar en parte dicha comunicacin con OpenNMS, pero el consumo se
disparara y ya no sera viable ya que los requerimientos de energa conllevaran una
mayor batera y placa solar mayor.
17

Existe un SO que se ha diseado para los dispositivos ZigBee y es el TinyOS que se trata
de un sistema operativo de cdigo abierto y el cual nos brindara la posibilidad de
implementar un pequeo agente con su propia MIB dentro del mdulo de comunicacin
ZigBee, pero hay que tener en cuenta que la filosofa de gestin de OpenNMS es que
quien realiza el Polling es el gestor OpenNMS hacia los dispositivos e interfaces y por
diseo esto no es operativo ya que la gran mayora de veces nuestro Mote estara en
suspensin. La idea a trabajar sera implementar la comunicacin en sentido contrario, es
decir, quien inicia el polling debe ser nuestro dispositivo ZigBee para anunciar su
existencia al router coordinador y ste como s que tiene implementado el agente
OpenNMS ser el que controlar los tiempos de respuesta y dems datos.
Una futura lnea de investigacin sera evaluar y probar todas las ideas expuestas ya que
los Motes son dispositivos muy verstiles y adems existe software de cdigo abierto que
abre un sinfn de posibilidades.

18

6. Otros Sistemas de Gestin de Red

Como ya se ha mencionado en apartados anteriores, otro de los sistemas de
monitorizacin es Nagios. Es el ms popular en lo que a sistemas de monitorizacin de
cdigo abierto se refiere y se ha establecido como un estndar de facto.

6.1. Nagios
Nagios es una popular herramienta de monitorizacin de servicios de red y dispositivos.
Administradores de sistemas de todo el mundo dependen de Nagios y de su galera de
plugins para mantener sus sistemas en funcionamiento y detectar los problemas antes de
que ocurran. Pero Nagios tiene un par de problemas:

Nagios carece de un soporte adecuado para entornos de gran magnitud, as como

de tcnicas corporativas contemporneas como pueda ser el clustering.

El cdigo base en C de Nagios, con diez aos de antigedad, presenta limitaciones

a la hora de adaptarlo a la rpida evolucin de las redes de hoy en da.

Existe una evolucin de Nagios que soluciona los dos problemas mencionados y se trata
de Shinken. El objetivo de Shinken es el de proporcionar un nuevo modelo multi-proceso
distribuido que se adapte bien a entornos distribuidos y heterogneos. El proyecto
Shinken se encuentra en una fase temprana y falta implementar ms funcionalidades. El
objetivo es asegurar una compatibilidad absoluta entre sus archivos y los de Nagios.

19

6.1.1. Caractersticas y funcionalidades

Nagios marca el estndar en la industria de monitoreo a grandes niveles por unas cuantas
razones. Este permite controlar la red informtica y solucionar problemas antes que los
usuarios los detecten. Nagios es un sistema estable, escalable, con soporte y extensible.

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.
NAgios cuenta con una muy importante cantidad de addons desarrollados por la
comunidad (ms de 200) que permiten extender las funcionalidades del sistema. Es un
software de cdigo abierto, con acceso completo al cdigo fuente, liberado bajo licencia
GPL.

Nagios es un sistema que cuenta con ms de 10 aos en desarrollo, es un sistema que

permite escalar hasta monitorear ms de 100,000 nodos, cuenta con gran reconocimiento,
ganador de mltiples premios. Actualmente cuenta con ms de 250.000 usuarios
alrededor del mundo. Tiene una lista de correos activa y una amplia comunidad a travs
del website.

6.1.2. Funcionalidades bsicas

Se destacan las siguientes caractersticas de funcionamiento:

20

Enviar de forma inmediata notificaciones de problemas va email, pager o telfonos

celulares.

Capacidad de notificar a mltiples usuarios.

Uso de su interfase web que permite ver informacin detallada de los estados de
los distintos componentes, reconocer problemas de forma rpida.

Permite reiniciar automticamente aplicaciones que hayan fallado, servicios y

equipos.

Permite agendar actualizaciones de hosts, servicios y componentes de la red.

Permite planificar las capacidades de los componentes a travs del monitoreo.

Permite generar reportes de disponibiidad SLA (Service Level Agreements), y

reportes histricos de alertas y notificaciones. Adems permite ver las tendencias
de los informes a travs de la integracin con Cactus y RRD.

Mltiples usuarios pueden acceder a la interfase web, adems cada usuario puede
tener una vista nica y restringida.

6.1.3. Estructura
Nagios tiene las siguientes caractersticas principales en cuanto a su estructura:

El sistema cuenta con un ncleo que forma la lgica de control de negocio de la

aplicacin, este contiene el software necesario para realizar la monitorizacin de
los servicios y de las mquinas de la red.

El sistema hace uso de diversos componentes que ya vienen en el paquete de

instalacin con la aplicacin, 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 monitorizacin y gestin basado en SNMP, sino
que realiza su labor basndose en una gran cantidad de pequeos mdulos
software que realizan chequeos de partes de la red.

Muestra los resultados de la monitorizacin y del uso de los diversos componentes

en una interfaz web a travs de un conjunto de CGIs y de un conjunto de pginas
HTML que vienen incorporadas, y que permiten al administrador una completa
visin de lo qu ocurre, en dnde ocurre y en algunos casos el por qu ocurre.

21

Por ltimo, si se compila para ello, Nagios guardar los histricos en una base de
datos para que al detener y reanudar el servicio de monitorizacin, todos los datos
sigan sin cambios.

Nagios permite monitorizar sistemas Windows mediante la instalacin de un agente

en la mquina a monitorizar, aunque la parte servidor de Nagios debe residir en un
servidor Unix/Linux.

7. Bibliografa y Referencias
-

Proyecto SIGNA, Aplicaciones de Monitoreo. Estudio de alternativas de cdigo

abierto.

Introduction to OpenNMS. Craig Gallen, 2009.

Desarrollo de un entorno para configuracin y monitorizacin de redes Zigbee.

Proyecto Fin de Carrera, Sergio Lillo Moreno.

Informe Tcnico: Protocolo ZigBee (802.15.4). Javier Martn y Daniel Ruiz. Junio
2007.

http://www.libelium.com/development/waspmote

http://www.opennms.org/

http://www.nagios.org/

22