1

Proyectos Multidisciplinares de las TIC-II. Máster en Telecomunicación 2012-2013.

Autor: Julio Jornet Monteverde.

2

Índice de contenido.

1. INTRODUCCIÓN. ............................................................................................................................ 3 1.1. SISTEMAS DE MONITOREO CON O SIN AGENTES .......................................................................................... 3

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

3. FUNCIONALIDADES ........................................................................................................................ 6 3.1. GESTIÓN DE EVENTOS Y ALARMAS ........................................................................................................... 6

3.1.1. Recolección de Eventos ............................................................................................................ 6 3.1.2. Correlación de Alarmas ........................................................................................................... 7 3.1.3. Notificaciones de Usuario y Escalados Programados .............................................................. 9 3.1.4. Integración de Trouble Tickets ................................................................................................. 9

3.2. RENDIMIENTO Y GESTIÓN DE SLAS ........................................................................................................ 10 3.2.1. Rendimiento y Gestión de recolección de datos .................................................................... 10 3.2.2. Visualización de Datos ........................................................................................................... 10 3.2.3. Gestión de SLAs ..................................................................................................................... 11

3.3. INTEGRACIÓN Y GESTIÓN DE CONFIGURACIÓN ......................................................................................... 11 3.3.1. Configuración unificada ........................................................................................................ 11 3.3.2. Descubrimiento de la Red ...................................................................................................... 12 3.3.3. Configuración de Interfaces ................................................................................................... 13 3.3.4. Integración ............................................................................................................................. 14

3.4. POLLER REMOTO ................................................................................................................................ 15

4. ARQUITECTURA ........................................................................................................................... 15 4.1. MEJORAS VERSIÓN 2.0. ....................................................................................................................... 16

5. IMPLEMENTACIÓN EN SPED .......................................................................................................... 17

6. OTROS SISTEMAS DE GESTIÓN DE RED .......................................................................................... 19 6.1. NAGIOS ............................................................................................................................................. 19

6.1.1. Características y funcionalidades .......................................................................................... 20 6.1.2. Funcionalidades básicas ........................................................................................................ 20 6.1.3. Estructura .............................................................................................................................. 21

7. BIBLIOGRAFÍA Y REFERENCIAS ...................................................................................................... 22

3

1. Introducción.

OpenNMS es una de las alternativas libres más destacadas para realizar tareas de

administración y gestión de redes, bajo sistemas Linux. Esta poderosa herramienta,

incorpora un paquete de funciones, que permiten controlar por completo todo el tráfico de

datos que se transmite a través de la red. OpenNMS es una aplicación fácil de utilizar.

Podemos manipular cada una de las características de la red, así como, analizar y detallar

cada uno de los archivos que se transfieren, y realizar una serie de tareas de gestión y de

conexiones de red.

Este software realiza un análisis de cada una de las conexiones entrantes y salientes de

nuestra red, con el principal objetivo de verificar si existen conexiones no autorizadas.

También, genera reportes completos de gestión, 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 gestión de red de nivel empresarial desarrollada en el

marco del modelo de código abierto. A diferencia de los productos de gestión de red que

están 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: páginas web, acceso a

bases de datos, DNS, DHCP, etc (aunque la información sobre elementos de la red

también está disponible ).

Como la mayoría de los servicios de red se proporcionan a través del protocolo TCP / IP,

OpenNMS está muy centrado en el nivel IP. El elemento básico de monitorización se

llama "interfaz", y una interfaz se identifica por una dirección IP. Los servicios se asignan

a las interfaces, y si una serie de interfaces que se descubren pertenecen al mismo

dispositivo (ya sea a través 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 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

4

monitoreo central.

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.

Sistemas con agentes

Ventajas

• 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

• 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

Ventajas

• 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

Desventajas

• Tiene métricas menos especificas por consiguiente se pueden realizar análisis 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 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

5

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.

2. El Proyecto OpenNMS Como ya se ha comentado, OpenNMS es un sistema de gestión de red orientado a

agente, y es la primera plataforma desarrollada bajo código 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 detección

automática de nodos centrales con más 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 discusión. 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 dirección del proyecto y

6

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 características.

3.1. Gestión de Eventos y Alarmas

3.1.1. Recolección de Eventos OpenNMS puede registrar todo tipo de eventos ocurridos: Trigers, evaluación de eventos,

automatización de acciones en función 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 recepción de

eventos. También se pueden enviar los eventos que se deseen via XML-RPC a otro

sistema de gestión remoto.

7

Los eventos se controlan con el proceso Eventd el cual recibe y graba toda la información.

Este proceso escucha el puerto 5817 por el cual los demás procesos envían peticiones e

incluso se pueden enviar desde sistemas externos a OpenNMS.

Listado de Eventos

3.1.2. Correlación de Alarmas Se utiliza un mecanismo de Alarma para manejar traps de recolección de alarmas o traps

de anulación de alarmas en un entorno de gestión de alarmas cíclico. Cuando se recibe

8

por primera vez un trap o disparo se recoge una alarma. Si se reciben sucesivos traps,

éstos se contarán 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 utilización es el más simple en un listado de alarmas.

El usuario también puede configurar reglas más sofisticadas de tratamiento de eventos de

alarmas incluso automatizándolo en función de un sofisticado análisis ya que posee un

motor de reglas.

Listado de Alarmas

Detalle de Alarma

9

3.1.3. Notificaciones de Usuario y Escalados Programados OpenNMS soporta múltiples 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 Notificación que se escalará en el tiempo a través

de una lista de usuarios si la alarma no se reconoce en un periodo de tiempo definido por

el usuario. El sistema también puede generar un sonido, un email o un mensaje

instantáneo para llamar la atención sobre la notificación. También existen mecanismos de

notificación tales:

- XMPP: Jabber, un protocolo de mensajería instantánea. - 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 genéricas.

Listado de Notificaciones

3.1.4. Integración de Trouble Tickets Si el mecanismo de escalado básico no es suficiente, OpenNMS también dispone de una

interface Trouble Ticket para integrarlo en el sistema con un número de incidencia.

10

3.2. Rendimiento y Gestión de SLAs

3.2.1. Rendimiento y Gestión de recolección de datos Como en otras herramientas de gestión de redes tales como Nagios o Cricket, OpenNMS

almacena datos en ficheros RRD. Se puede utilizar la herramienta RRD para hacer la

recolección de datos pero la librería preferida es JRobin la cual es una implementación

Java de RRD.

OpenNMS ya lleva implementada una MIBS (base de datos SMNP) que soporta la gran

mayoría 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 programación de la recolección

de datos se controla totalmente por un proceso Java dentro de OpenNMS el cual hace

que la solución sea muy escalable.

Los datos pueden recogerse desde varias fuentes distintas: sondeo SNMP, traps de

gestión, mensajes ASCII tipo syslog, TL1, JMX. También existe una integración con

Nagios que permite la utilización de plugins de Nagios. OpenNMS también se ha

integrado con SNORT.

3.2.2. Visualización de Datos OpenNMS presenta los datos de rendimiento en forma de gráficos. Estos gráficos también

se pueden exportar en forma de informes de rendimiento.

También se pueden definir umbrales que generan alarmas cuando hay cambios en los

datos. OpenNMS puede realizar transacciones sintéticas 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.

11

3.2.3. Gestión de SLAs Se pueden definir umbrales en los SLAs que generarán una alarma en cuanto se rebasen

y pueden escalarse en función de las reglas definidas. A cada punto de recolección de

datos de rendimiento se le puede asignar dos umbrales, uo superior y otro inferior, para

evitar los rebotes de alarmas.

3.3. Integración y Gestión de Configuración

3.3.1. Configuración unificada Toda la configuración de OpenNMS está almacenada en archivos XML y se encuentra

dentro de un directorio. Muchas de estas configuraciones también se exponen en la

interface de usuario. Las configuraciones incluyen los tiempos de barrido, mapeado de

traps del tipo eventos/alarmas, gestión de MIBs, etc.

12

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. Automáticamente 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 configuración de los servicios con un fichero tipo XML. Esta

configuración 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

13

servicios interrogando y registrando los tiempos de respuesta utilizando transacciones

sintéticas.

3.3.3. Configuración de Interfaces También se pueden utilizar archivos XML conteniendo la configuración 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 automático que está integrado

con el sistema RANCID (RANCID – Really Awesome New Cisco confIg Differ

http://www.shrubbery.net/rancid/), y también con PUPPET.

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

Ejemplo de Porvisionamiento Manual

Ejemplo de Provisionamiento externo con XML

14

3.3.4. Integración OpenNMS posee numerosos puntos de integración para la paginación, sonidos de

alarmas, email, tratamiento de tickets/incidencias, etc.

El sistema está preparado para utilizar mapas para mostrar la topología de la red tal y

como se refleja a continuación.

15

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 ejecutándose, el plugin

interroga los servicios de los nodos centrales utilizando transacciones sintéticas. Una vez

se tienen los resultados, se envían al servidor OpenNMS.

4. Arquitectura A continuación se muestra un diagrama de bloques de la arquitectura OpenNMS:

16

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

• API Servicio Detector: Detección de Servicios, Interface Java.

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

• API Servicio Recolección: 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 estratégicas: Plugin para crear nuevos métodos de notificación. Interface Java.

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

• API Provisión Adaptador: Plugin para la integración de CMS, EMS, sistemas de inventariado, etc. Interface Java.

A continuación se muestra un ejemplo de cómo se comunican los procesos internos:

4.1. Mejoras versión 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)

17

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

- Se ha implementado una API REST para poder acceder utilizando tecnologías 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.

- También se han reducido el número de reinicios requeridos en el sistema por

cambios en la configuración.

- Se ha implementado un módulo de soluciones de tolerancia a fallos.

5. Implementación en SPED Tal y como se ha planteado el Sistema de Prevención, Extinción de incendios forestales y

Detección 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 grabación de imágenes 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 también

implica que podamos supervisar las interfaces de éste y por ello nuestra red de

transmisión compuesta de enlaces punto-punto o punto-multipunto.

En cuanto a los Motes, no podemos utilizar el sistema OpenNMS ya que estos

dispositivos están configurados para utilizar la tecnología ZigBee como medio de

comunicación hasta el router y todavía no está soportado Zigbee en OpenNMS. Además,

existe una restricción que hace que los Motes no puedan implementar un agente y es que

el software de control está especialmente diseñado para tener un bajo consumo. Esto

conlleva a que el Mote esté la mayor parte del tiempo en modo suspensión y solamente

se despierte para enviar los valores de los sensores y para notificar al coordinador de su

existencia. También tenemos la limitación de la memoria ya que estos dispositivos tienen

muy poca memoria.

Existe un modelo de Mote que implementa un interface WIFI para la comunicación y que

nos permitiría gestionar en parte dicha comunicación con OpenNMS, pero el consumo se

dispararía y ya no sería viable ya que los requerimientos de energía conllevarían una

mayor batería y placa solar mayor.

18

Existe un SO que se ha diseñado para los dispositivos ZigBee y es el TinyOS que se trata

de un sistema operativo de código abierto y el cual nos brindaría la posibilidad de

implementar un pequeño agente con su propia MIB dentro del módulo de comunicación

ZigBee, pero hay que tener en cuenta que la filosofía de gestión de OpenNMS es que

quien realiza el Polling es el gestor OpenNMS hacia los dispositivos e interfaces y por

diseño esto no es operativo ya que la gran mayoría de veces nuestro Mote estaría en

suspensión. La idea a trabajar sería implementar la comunicación 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 demás datos.

Una futura línea de investigación sería evaluar y probar todas las ideas expuestas ya que

los Motes son dispositivos muy versátiles y además existe software de código abierto que

abre un sinfín de posibilidades.

19

6. Otros Sistemas de Gestión de Red Como ya se ha mencionado en apartados anteriores, otro de los sistemas de

monitorización es Nagios. Es el más popular en lo que a sistemas de monitorización de

código abierto se refiere y se ha establecido como un estándar de facto.

6.1. Nagios

Nagios es una popular herramienta de monitorización de servicios de red y dispositivos.

Administradores de sistemas de todo el mundo dependen de Nagios y de su galería 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 técnicas corporativas contemporáneas como pueda ser el clustering.

- El código base en C de Nagios, con diez años de antigüedad, presenta limitaciones

a la hora de adaptarlo a la rápida evolución de las redes de hoy en día.

Existe una evolución 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 heterogéneos. El proyecto

Shinken se encuentra en una fase temprana y falta implementar más funcionalidades. El

objetivo es asegurar una compatibilidad absoluta entre sus archivos y los de Nagios.

20

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

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 (más de 200) que permiten extender las funcionalidades del sistema. Es un

software de código abierto, con acceso completo al código fuente, liberado bajo licencia

GPL.

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.

6.1.2. Funcionalidades básicas Se destacan las siguientes características de funcionamiento:

21

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

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

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

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

22

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

7. Bibliografía y Referencias

- Proyecto SIGNA, Aplicaciones de Monitoreo. Estudio de alternativas de código

abierto.

- Introduction to OpenNMS. Craig Gallen, 2009.

- Desarrollo de un entorno para configuración y monitorización de redes Zigbee.

Proyecto Fin de Carrera, Sergio Lillo Moreno.

- Informe Técnico: Protocolo ZigBee (802.15.4). Javier Martín y Daniel Ruiz. Junio

2007.

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

- http://www.opennms.org/

- http://www.nagios.org/