Proyecto Fin de Carrera

PROYECTO FIN DE CARRERA
Ttulo
Adecuacin, mejora y optimizacin de la plataforma de

monitorizacin de red y sistemas en la UR con
herramientas de software libre
Autor/es
Eduardo Laborda Pl
Director/es
Fernando Ros Puente y Mara Vico Pascual Martnez-Losa

Facultad
Facultad de Ciencias, Estudios Agroalimentarios e Informtica

Titulacin
Proyecto Fin de Carrera
Departamento
Matemticas y Computacin
Curso Acadmico
2012-2013
Adecuacin, mejora y optimizacin de la plataforma de monitorizacin de red
y sistemas en la UR con herramientas de software libre, proyecto fin de carrera
de Eduardo Laborda Pl, dirigido por Fernando Ros Puente y Mara Vico Pascual
Martnez-Losa (publicado por la Universidad de La Rioja), se difunde bajo una Licencia
Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported.
Permisos que vayan ms all de lo cubierto por esta licencia pueden solicitarse a los
titulares del copyright.
El autor
Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: [email protected]
Facultad
Facultad de Ciencias, Estudios Agroalimentarios e Informtica

Titulacin
Ingeniera Tcnica en Informtica de Gestin

Ttulo
Adecuacin, mejora y optimizacin de la plataforma de monitorizacin de red y sistemas en

la UR con herramientas de software libre.
Autor/es
Eduardo Laborda Pl
Director/es
Fernando Ros y Mara Vico Pascual

Departamento
Matemticas y computacin
Curso acadmico
2012-2013
PFC: Adecuacin, mejora y optimizacin de la plataforma de monitorizacin
de red y sistemas en la UR con herramientas de software libre.
1 Contexto ................................................................................................................... 5
2 Glosarios de trminos ............................................................................................... 5
3 Documento de Objetivos del proyecto ..................................................................... 6
3.1 Generalidades ................................................................................................... 6
3.2 Antecedentes y Situacin actual ....................................................................... 6
3.3 Alcance ............................................................................................................. 7
3.4 Objetivos del proyecto...................................................................................... 9
3.5 Metodologa.................................................................................................... 10
3.6 Entregables ..................................................................................................... 11
3.7 Estructura de descomposicin de tareas ......................................................... 12
3.8 Riesgos ........................................................................................................... 19
3.9 Software de monitorizacin............................................................................ 19
3.10 Estudio de alternativas en herramientas de monitorizacin ........................... 20
3.10.1 Nagios..................................................................................................... 20
3.10.2 Pandora ................................................................................................... 20
3.10.3 Zabbix..................................................................................................... 21
3.10.4 Centreon ................................................................................................. 22
3.10.5 FAN (Full Automated Nagios) ............................................................... 22
3.10.6 Anlisis y seleccin de la herramienta de monitorizacin ..................... 23
4 Arquitectura de la plataforma de monitorizacin ................................................... 24
5 Anlisis del sistema de monitorizacin .................................................................. 27
5.1 Usuarios de la monitorizacin ........................................................................ 27
5.2 Host de la monitorizacin............................................................................... 28
5.3 Servicios de la monitorizacin ....................................................................... 30
5.3.1 Identificacin de recurso a monitorizar .................................................. 32
5.3.2 Definicin de los valores crticos (Warning, Critical) del recurso ......... 33
5.3.3 El identificador de objeto (OID) de los recursos.................................... 34
5.4 Servicios para Windows ................................................................................. 35
5.5 Plugins de la monitorizacin .......................................................................... 37
5.6 Eleccin de servidor de correo ....................................................................... 42
5.7 Comunicacin y permisos con servidores ...................................................... 42
5.8 Copia de Seguridad del sistema...................................................................... 43
6 Implementacin del sistema de monitorizacin en Comunicaciones..................... 45
6.1 Implementacin de Host................................................................................. 45
6.1.1 Lista de equipos a monitorizar............................................................... 45
6.1.2 Plantillas y grupos de host ...................................................................... 45
6.1.3 Observaciones......................................................................................... 47
6.2 Implementacin de servicios de Comunicaciones.......................................... 47
6.2.1 Identificacin de recursos....................................................................... 47
6.2.2 Definicin de los valores crticos (Warning, Critical) de los recursos... 48
6.2.3 Identificador de objeto (OID) ................................................................. 49
6.2.4 Identificacin y descripcin de plantillas de servicios ........................... 50
6.3 Implementacin de plugins comunicaciones.................................................. 52
6.3.1 Comando UR_check_load_linux............................................................ 52
6.3.2 Comando UR_check_cpu_netapp .......................................................... 53
6.3.3 Comando Check_disk............................................................................. 53
6.3.4 Comando UR_check_disk_firewall........................................................ 53
Pgina 2 de 135
6.3.5 Comando UR_check_disk_linux............................................................ 54

6.3.6 Comando UR_check_disk_netapp ......................................................... 55
6.3.7 Comando UR_check_memory ............................................................... 56
6.3.8 Comando UR_check_ethernet................................................................ 57
6.3.9 Comando UR_check_radio .................................................................... 58
7 Implementacin de la monitorizacin de Sistemas ................................................ 59
7.1 Arquitectura de la monitorizacin Sistemas................................................... 59
7.2 Instalacin del poller de Sistemas .................................................................. 61
7.3 Implementacin de Host en Sistemas............................................................. 61
7.4 Implementacin de los servicios en Sistemas................................................. 62
7.4.1 Identificacin de servicios ...................................................................... 62
7.4.2 Valores crticos ....................................................................................... 63
7.5 Implementacin de plugins de Sistemas......................................................... 64
7.5.1 Comando ur_ceck_cert .......................................................................... 64
7.5.2 Comando ur_check_connections............................................................ 64
7.5.3 Comando ur_check_tunnel_dialnet ........................................................ 65
7.5.4 Comando ur_check_virtual_host............................................................ 65
7.6 Servicios Windows ......................................................................................... 68
7.6.1 check_centreon_snmp_cpu..................................................................... 68
7.6.2 check_centreon_snmp_remote_storage.................................................. 68
7.6.3 check_centreon_snmp_memory ............................................................. 69
7.6.4 check_centreon_snmp_process .............................................................. 69
8 Mejoras del Sistema de monitorizacin ................................................................. 70
8.1 Copia de Seguridad del sistema...................................................................... 70
8.2 Mapas de red................................................................................................... 71
8.2.1 Mapas de la monitorizacin de comunicaciones .................................... 72
8.2.2 Mapas de la monitorizacin de sistemas ................................................ 74
9 Pruebas realizadas en la monitorizacin................................................................. 77
10 Gestin real del proyecto.................................................................................... 81
10.1 Conclusiones................................................................................................... 84
10.2 Informe del supervisor de la monitorizacin.................................................. 85
11 Bibliografa......................................................................................................... 86
12 Anexos ................................................................................................................ 87
12.1 NRPE y SNMP ............................................................................................... 87
12.1.1 NRPE ...................................................................................................... 87
12.1.2 SNMP (Protocolo Simple de Administracin de Red)........................... 88
12.2 Manual de usuario .......................................................................................... 93
12.3 Actas de reunion ........................................................................................... 111
12.3.1 Acta 1.................................................................................................... 111
12.3.2 Acta 2.................................................................................................... 112
12.3.3 Acta 3.................................................................................................... 113
12.3.4 Acto 4 ................................................................................................... 114
12.3.5 Acta 5.................................................................................................... 116
12.3.6 Acta 6.................................................................................................... 118
12.3.7 Acta 7.................................................................................................... 119
12.3.8 Acta 8.................................................................................................... 121
12.3.9 Acta 9.................................................................................................... 122
12.3.10 Acta 10.............................................................................................. 123
12.3.11 Acta 11.............................................................................................. 124
Pgina 3 de 135
12.3.12 Acta 12.............................................................................................. 125

12.3.13 Acta 13.............................................................................................. 126
12.3.14 Acta 14.............................................................................................. 127
12.3.15 Acta 15.............................................................................................. 128
12.3.16 Acta 16.............................................................................................. 130
12.3.17 Acta 17.............................................................................................. 131
12.3.18 Acta 18.............................................................................................. 132
12.3.19 Acta 19.............................................................................................. 133
12.3.20 Acta 20.............................................................................................. 134
12.3.21 Acta 21.............................................................................................. 135
Pgina 4 de 135
1 Contexto
La monitorizacin es una parte muy importante dentro de las redes de comunicacin,
por ello, tener un sistema de monitorizacin eficiente es importante, ya que con l
podemos identificar errores y problemas en las comunicaciones de forma rpida y as
poder subsanarlos de forma eficaz.
La Universidad de la Rioja tiene un sistema de monitorizacin de redes el cual quiere

ser actualizado y mejorado. Este proyecto intentar mejorar el sistema actual de
monitorizacin y ampliarlo. En esta mejora queremos aumentar los objetos a
monitorizar y hacerlo de una manera eficiente.
La realizacin de este proyecto surge durante la estancia en el servicio informtico de la

universidad, durante el periodo de una beca de colaboracin. Al empezar este trabajo
para la beca, se ve que puede ser viable como proyecto fin de carrera, y se propone su
realizacin. El proyecto dur todo el ao de la beca de colaboracin, ms 5 meses que
se ha estado como prcticas en el servicio informtico.
2 Glosarios de trminos
SNMP: Protocolo Simple de Administracin de Red (Vase Anexos).
NRPE: Ejecutor de plugins locales en equipos remotos (Vase Anexos).
Host: Servidor o dispositivo de red.
Servicio: Monitorizacin de un recurso de un servidor.
Plugin: Comando para realizar servicios de monitorizacin.
MIB: Base de Informacin de Administracin.
OID: Identificador de objeto.
LDAP: Protocolo Ligero de Acceso a Directorios.
Firewall: Parte de un sistema o una red que est diseada para bloquear el acceso no
autorizado.
Switches: dispositivo digital lgico que tiene como funcin interconectar dos o ms
segmentos de red.
SWAP: Memoria virtual.
AP: Punto de acceso.
NAS: Dispositivos de almacenamiento especficos a los que se accede desde los
equipos a travs de protocolos de red.
DNS: Sistema de nombres de dominio.
DHCP: Protocolo de configuracin dinmica de host.
NDOUTILS: Addon que permite almacenar la configuracin, tests y resultados de
Nagios.
VMWare ESX y ESXi: Plataformas de virtualizacin.
TCP: Protocolo de Control de Transmisin.
Warning: Valor de peligro para los servicios, se produce un aviso al responsable del
recurso que produce el aviso.
Critical: Valor crtico para los servicios, se produce un aviso al responsable del recurso
que produce el aviso.
Pgina 5 de 135
3 Documento de Objetivos del proyecto
3.1 Generalidades
En este proyecto se quiere realizar la implantacin de un sistema de monitorizacin para

una parte de la red de la universidad de La Rioja.
La parte de la red de la UR que se quiere monitorizar se divide en dos:

Comunicaciones
Sistemas
Estas dos redes tienen multitud de host, y de cada uno tendremos que monitorizar una
serie de recursos.
3.2 Antecedentes y Situacin actual
El servicio informtico de la Universidad de la Rioja lleva una monitorizacin de las

redes de la universidad, actualmente la plataforma de monitorizacin que se utiliza es
Nagios (Anexos).
Nagios es un software libre muy utilizado que monitoriza redes, Nagios puede vigilar
los equipos (hardware) y servicios (software) que se especifiquen, mandando alertas
cuando se produce un comportamiento no deseado. Entre sus caractersticas principales
figuran la monitorizacin de servicios de red, la monitorizacin de los recursos de
sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los
puertos...), independencia de sistemas operativos y la posibilidad de programar plugins
especficos para nuevos sistemas.
El servicio informtico de la UR tiene actualmente dos instancias de Nagios donde se

monitorizan las redes de sistemas y comunicaciones de la UR.
Estas dos instancias de Nagios son las que se quieren ampliar y mejorar, esta mejora en
la monitorizacin se quiere realizar por las siguientes razones:
Facilitar la configuracin del sistema de monitorizacin. Nagios es una

herramienta muy potente de monitorizacin, pero es muy difcil de configurar,
sus archivos de configuracin tienen una sintaxis nica, y se ha de conocer bien
para poder manejar la configuracin de Nagios y realizar cambios. Cualquier
error en la sintaxis de los archivos de configuracin hace que Nagios deje de
funcionar.
Actualizar la interfaz del sistema de monitorizacin. Aunque Nagios nos

viene con una interfaz Web para poder visualizar la monitorizacin, esta no tiene
muchas posibilidades a la hora de ver algn tipo de grfico o esquema de los
datos de la monitorizacin, en los que poder ver o prevenir el comportamiento
de los recursos monitorizados.
Pgina 6 de 135
Mejorar los mapas de red. Nagios nos da la posibilidad de visualizar unos

mapas de red, muy rudimentarios. Dependiendo de las relaciones entre los host
que monitorizamos, este mapa que nos crea es muy general y no da una visin
acertada de la red monitorizada.
Cambios en el protocolo de monitorizacin. En la monitorizacin, se estn

utilizando comandos NRPE para monitorizar los recursos de los host, este
protocolo se quiere cambiar a SNMP.
Generacin, almacenamiento y consulta en tiempo real de histricos.

Tendremos que poder almacenar los resultados de la monitorizacin, estos datos
podrn ser consultados en un futuro para ver tendencias en los recursos
monitorizados.
Disponibilidad de un sistema de recuperacin ante desastres. Se podrn

realizar backups de los archivos de configuracin y de las BBDD del sistema de
monitorizacin, para que en caso de fallo en el sistema no perdamos nada de
informacin.
Herramientas OpenSource. El software a utilizar para nuestro sistema de

monitorizacin ha de ser un software libre.
Para realizar la ampliacin y mejora del sistema de monitorizacin se estudiarn varias

alternativas de software y se elegir la ms adecuada para nuestra monitorizacin.
3.3 Alcance
La monitorizacin que se ha de realizar abarcar la parte de Comunicaciones y

Sistemas, se han de implementar todos los servicios previos que hubiera en la
monitorizacin antigua, adems de los nuevos servicios que necesitemos.
Se han de desarrollar los plugins necesarios para realizar la monitorizacin, o bien

extraerlos de algn medio, ya sea de la configuracin de monitorizacin previa, o
mediante Internet.
La monitorizacin abarcar los siguientes host y recursos:
Por la monitorizacin de comunicaciones:
Host:
Switches
AP
Cabinas de disco
Firewall
Pgina 7 de 135
Recursos:
Disponibilidad del Host

Memoria RAM
Memoria SWAP
Discos Duros
Uso de CPU
Estado de los puertos Ethernet
Por la monitorizacin de sistemas:
Host:
Servidores DNS
Servidores DHCP
Firewall
Equipos y servidores de correo
Servidores Virtuales
Servidores Proxy Web
Servidores LDAP
Servidores NAS
Servidores de BBDD
Recursos:
Disponibilidad del Host

Memoria RAM
Memoria SWAP
Discos Duros
Uso de CPU
Caducidad de certificados
Host virtuales
Servicios especficos (DNS, DHCP, Web, Balanceos)
Se tendr que poder realizar una copia de seguridad de la herramienta de monitorizacin

a travs de la Web, poniendo un link que nos enve a una pgina donde poder crear la
copia de seguridad de forma automtica.
Aspectos que no se realizarn durante el proyecto:
La monitorizacin solo incluye los equipos que hay en el CPD del servicio
informtico, los cuartos de comunicaciones del campus y los puntos acceso a la
red de los edificios, no se incluye ningn equipo personal, ni los ordenadores de
los despachos, ni los ordenadores de las aulas de los edificios del campus de la
UR.
Pgina 8 de 135
Realizacin de Event Handler, estos eventos se utilizan para solucionar un

problema en un servicio automticamente, por ejemplo al dar un problema un
servicio http, que ste se reinicie automticamente.
Desarrollar una nueva herramienta de monitorizacin.
Desarrollar un protocolo de comunicacin propio.
Una monitorizacin de redes necesita un mantenimiento continuo, ya que se
tienen que ir solucionando las incidencias que se van produciendo, dando
recurso de alta o baja, cambiando servicio por ello nosotros solo nos
encargaremos de este mantenimiento durante el tiempo que duren las prcticas
en el servicio informtico, una vez finalice ese tiempo, se encargarn los
empleados del servicio informtico.
3.4 Objetivos del proyecto
El objetivo del proyecto es la mejora y optimizacin de la plataforma de monitorizacin

de red y sistemas de la UR, para ello se estudiarn diferentes opciones de software libre
y se elegir la ms conveniente para el proyecto.
Los aspectos a cubrir en el proyecto son los siguientes:
Estudio de distintas alternativas de software y eleccin del mismo.
Instalacin del software libre, configuracin y desarrollo de los mdulos

necesarios para capturar y mostrar los datos de funcionamiento de los equipos
del CPD.
Identificacin de los equipos del CPD a monitorizar y definicin de su

criticidad.
Monitorizacin de los componentes reflejando los parmetros de supervisin y

control que permita localizar de forma inmediata el origen de las incidencias que
puedan producirse sobre cualquiera de los equipos implicados.
Captura de los datos y procesado de la informacin para su posterior

visualizacin como grficos en una interfaz Web, para poder ser analizados por
los usuarios del sistema de monitorizacin, de forma que se puedan ver
comportamientos en los recursos monitorizados y as realizar un mantenimiento
preventivo y proactivo.
Creacin de mapas de red que reflejen la distribucin de los dispositivos y los

servicios monitorizados.
Creacin de back-up de la plataforma para posible restauracin en caso de fallo

del sistema.
Pgina 9 de 135
Cambio en el protocolo de los comandos de monitorizacin de NRPE a SNMP

(siempre que sea posible).
Monitorizacin de tanto equipos Linux / Unix como Windows, teniendo que

realizar servicios de monitorizacin especficos para cada sistema operativo.
3.5 Metodologa
Para la realizacin del proyecto se cree que la metodologa ms conveniente a utilizar es

la del Crculo de Deming (PDCA), esta decisin se basa en que durante la realizacin
del proyecto se realizarn reuniones peridicas con el codirector con el cual se decidirn
las tareas a realizar y a comprobar los avances realizados en el proyecto.
Planificar
En cada reunin con el codirector tratamos los puntos que vamos a hacer y mejorar
durante las reuniones de seguimiento a los largo del proyecto.
Hacer
Durante las semanas siguientes a la reunin se realizan los puntos tratados en ella
implementando la monitorizacin.
Verificar
Una vez terminado de implementar los puntos tratados en la reunin se realiza una
nueva para verificar las mejoras realizadas y plantear el siguiente paso.
Actuar
En caso de que no se termine la tarea planteada en la reunin anterior se vern las

dificultades encontradas y se tratarn de solucionar para seguir avanzando.
Pgina 10 de 135
3.6 Entregables
Memoria
Manual de usuario
Gestin del proyecto
Presentacin
Pgina 11 de 135
3.7 Estructura de descomposicin de tareas
Pgina 12 de 135
Direccin y gestin
Esta tarea se divide a su vez en tres subtareas distintas:
Entorno de trabajo: En esta tarea se nos mostrar dnde trabajaremos en el

sistema informtico, en qu trabajaremos y cul ser el horario para la
realizacin del proyecto.
o Tiempo estimado: 1 hora
Nuevas herramientas: Se usar tiempo en investigacin, anlisis, estudio,

seleccin y aprendizaje de nuevas herramientas para la realizacin del proyecto,
as como tecnologas que no se han visto hasta el momento.
o Tiempo estimado: 60 horas
Presentacin de las nuevas herramientas: Realizacin de una presentacin con al

codirector sobre las herramientas a utilizar en el proyecto.
Mantenimiento: En esta tarea se realizarn los cambios en los datos, as como

crear nuevos Host, aadir nuevos servicios o quitar alguno existente. Estos
cambios se producen durante todo el proyecto ya que se hacen a peticin del
responsable del servicio informtico in situ, dado que las redes y sistemas son
entornos dinmicos, y su estructura y servicios van evolucionando con el tiempo
a lo largo del desarrollo de este proyecto.
o Tiempo estimado: Esta tarea se realizar durante todo el proyecto
Reuniones con el tutor: Se realizarn reuniones con el codirector del proyecto

para solventar las dudas, chequear los avances, cambios y mejoras que se van
realizando en el proyecto. De cada reunin se realizar un acta con todos los
puntos hablados en la reunin y tareas propuestas hasta la siguiente revisin.
Habitualmente se han realizado una media de 2 reuniones al mes, cuyas fechas
se han programado segn la complejidad de las tareas propuestas en cada una de
ellas.
Elaboracin del DOP
Conocimientos del SI: Se ha de aprender el funcionamiento del servicio

informtico, infraestructuras de sistema, comunicaciones, e integracin de
tecnologas.
o Tiempo estimado:40 horas
Identificacin de requisitos: Se identificarn los objetivos que se van a realizar

en el proyecto.
Pgina 13 de 135
Descomposicin de tareas: Iremos descomponiendo el proyecto en subtareas

hasta que podamos valorar el tiempo a invertir en solucionar el problema.
Diseo
Diagrama de arquitectura: Realizaremos un diagrama de la arquitectura del

sistema.
Anlisis del sistema de monitorizacin
Anlisis de instalacin del software: Analizaremos qu herramientas vamos a

instalar en el servidor de monitorizacin.
Anlisis de Host: en esta tarea analizaremos los Host, veremos cules han de ser
aadidos y cmo.
Anlisis de servicios: en esta tarea analizaremos los servicios de

monitorizacin.
Anlisis de plugins: En esta tarea analizaremos los plugins.
Implementacin de Sistemas y Comunicaciones
Instalacin del software: instalaremos las herramientas que hemos decidido tener
en el servidor de monitorizacin.
Implementacin de Host: en esta tarea aadiremos los Host que tenemos al

software.
Pgina 14 de 135
Implementacin de servicios: en esta tarea aadiremos los servicios.
Implementacin de plugins: En esta tarea implementaremos los plugins

necesarios para el funcionamiento de los servicios.
Servicios Windows: En esta tarea implementaremos los plugins necesarios para

el funcionamiento de los servicios para Windows.
Pruebas
Pruebas en el sistema: Realizaremos pruebas a cada paso para verificar que todo
funciona correctamente.
o Tiempo estimado: 5
Pruebas en los servicios: Pruebas realizadas para comprobar que los servicios
funcionan correctamente.
Pruebas servicios Windows: Pruebas realizadas para comprobar que los

servicios Windows funcionan correctamente.
Manual de usuario
Redaccin de manual de usuario: Realizacin de un manual de usuario

exhaustivo.
Memoria
Recopilacin de informacin: durante todo el proceso se ir recopilando

informacin de los avances y cambios en el proyecto.
Redaccin de la memoria: Se redactar la memoria con toda la informacin

recopilada hasta el momento y se le dar formato.
Pgina 15 de 135
Preparar defensa
Presentacin: Realizacin de la presentacin para la defensa del proyecto.
Segn esta estimacin nos saldran un total de 752 horas aproximadamente, que
corresponden al tiempo que se estar en la beca de colaboracin.
Pgina 16 de 135
Pgina 17 de 135
El proyecto se realizar durante el horario de la beca de colaboracin con la UR, de

lunes a viernes entra las 9:00 y la 13:00, dedicando 4 horas a la realizacin del
proyecto, llegando hasta 5 si fuese necesario recuperar tiempo. La beca tiene una
duracin del 1 de octubre del 2011 al 31 de julio del 2012, durante ese tiempo tendr
que realizarse el proyecto.
L M X J V S D
9:00-10:00
10:00:11:00
11:00-12:00
12:00-13:00
13:00-14:00
Horas para realizar el proyecto

Horas de refuerzo
El proyecto solo podremos realizarlo durante las horas de la beca, ya que es cuando
tenemos acceso al material para realizar el proyecto, fuera del servicio informtico no
tenemos acceso a los servidores y la informacin y por lo tanto no podemos avanzar en
determinados puntos como la implementacin del sistema.
Hay que tener en cuenta tambin los das que son festivos en la Universidad y por lo
tanto el Servicio informtico est cerrado, y las vacaciones de semana santa y
navidades, que son 3 semanas en las que est cerrada la universidad.
A continuacin se muestra un grfico con el porcentaje de tiempo que se invertir en

cada tarea.
Direccin y gestin
Elaboracin del DOP
3% 3% 10% Diseo
7%
10%
Analisis del sistema de
7% monitorizcin
Implementacin de Sistemas y
Comunicaciones
38% Pruebas
22%
Manual de usuario
Memoria
Pgina 18 de 135
3.8 Riesgos
Enfermedad o accidente por parte del proyectante en el desarrollo del

proyecto.
Si el proyectante sufre una enfermedad o un accidente el cual le imposibilite continuar

con el desarrollo normal de proyecto, se realizar el pertinente reajuste en la
planificacin inicial, lo cual conllevar un retraso en la entrega final.
Cambios en las especificaciones del programa.
En el transcurso del proyecto pueden surgir nuevas especificaciones de requisitos, as

como cambios en la arquitectura del sistema, esto puede retrasar el proyecto por lo que
habra que ajustar los tiempos de realizacin del mismo.
Cambio en las horas dedicadas al proyecto.
Las horas dedicadas el proyecto se realizan dentro del servicio informtico, por lo tanto
los das que est cerrado o en la finalizacin de las prcticas ya no se podra tener
acceso al sistema y tendra que pedirse permisos especiales, esto puede tardar tiempo
hasta que se concedan.
Incendios, Inundaciones, (Daos en el Hardware)
En caso de incendio o inundaciones, tendremos que estar preparados mediante copias de

seguridad, para poder recuperar el trabajo perdido cuanto antes.
Permisos y acceso
Dado que estamos con muchos equipos puede que algunos servicios requieran hacer
cambios en los equipos, para ello tenemos que tener acceso a esos equipos o que los
cambios los realice alguien con acceso del servicio informtico, esto puede demorar la
implantacin del proyecto.
3.9 Software de monitorizacin
El software que tenemos que buscar tiene que cumplir los siguientes requisitos:
Ha de ser software libre, sin ningn coste.

La herramienta ha de ser de fcil comprensin.
Ha de dar soporte en toda la monitorizacin de la red de la UR, en torno a 300
servidores y dispositivos, si estimamos que cada uno tendr 5 servicios tenemos
1500 servicios monitorizados.
Tiene que tener la posibilidad de almacenar los datos de la monitorizacin.
Se han de poder visualizar mapas de red.
Pgina 19 de 135
3.10 Estudio de alternativas en herramientas de monitorizacin
En este apartado presentaremos diferentes alternativas para la herramienta de

monitorizacin, para finalmente seleccionar la ms conforme a nuestras necesidades.
Herramientas de monitorizacin:
Nagios
Pandora
Zabbix
Centreon
FAN (Full Automated Nagios)
3.10.1 Nagios
Nagios es un software libre para monitorizar sistemas de redes, este sistema de

monitorizacin funciona bajo Linux, este es capaz de enviar alertas por email, SMS o
mensaje instantneo al cliente cuando se produce una incidencia en los recursos
monitorizados.
Nagios tiene un sistema de plugins externos, estos plugins se utilizan para monitorizar
los recursos de los equipos que se quieren monitorizar, estos son los encargados de
recoger los datos y enviarlos a Nagios.
Nagios es la herramienta ms utilizada en cuanto a software de monitorizacin, con lo

que tiene un soporte muy grande con foros, webs, y guas con los que ayudarnos en la
implementacin y en los posibles inconvenientes que tengamos durante su utilizacin.
Aunque la configuracin es poco amigable, est basado en Web, donde podremos

consultar el estado actual de nuestros equipos, histricos e informes. Su sistema de
alarmas es perfecto para, de un vistazo, ver qu est fallando dentro de nuestra red.
3.10.2 Pandora
Pandora FMS es un software libre de monitorizacin, aunque tiene una versin libre,
tambin cuenta con una versin de pago especial para empresas, est especialmente
diseado para grandes entornos.
Pandora FMS es capaz de enviar alertas mediante email, SMS o mensaje instantneo
cuando se produce una incidencia en alguno de los recursos monitorizados.
Pgina 20 de 135
Pandora utiliza un sistema de agentes para recoger la informacin de los recursos a

monitorizar y los envan al servidor central. Pandora no solo es capaz de monitorizar
elementos de red y sus recursos tambin, es capaz de monitorizar factores ambientales,
como la temperatura, y otro tipo de cosas que no tienen nada que ver con las redes.
Pandora DMS puede monitorizar tanto equipos Linux como Windows mediante SNMP.
Algunas de las caractersticas principales de Pandora FMS son:
Monitorizacin multiplataforma, Solaris, GNU/Linux, Windows

Adaptabilidad total, servicios, aplicaciones, puertos, procesos, ficheros log u
otra fuente de informacin.
Monitorizacin remota.
Gestin y lanzamiento de alertas adaptables.
Generacin de informes personalizada.
Gestin Web.
Arquitectura Cliente-Servidor.
Alta capacidad de procesamiento.
3.10.3 Zabbix
Zabbix en una herramienta de monitorizacin de bajo coste, capaz de recoger datos de

cualquier aplicacin o servidor, con un sistema de envo y captura de datos a travs de
sus agentes. Es importante sealar que Zabbix es capaz de monitorizar, adems, equipos
Windows, AIX, FreeBSD, HP-UX, OpenBSD y Solaris desde dentro y personalizar
sus agentes con parmetros definidos por el usuario.
La ventaja de Zabbix reside en su interface Web, soportado por una base de datos SQL
(MySQL, PostgreSQL o SQLite).
Posee un sistema proactivo (Acciones) que permite solucionar automticamente los

problemas, un sistema de monitorizacin, alertas y visualizacin de grficos que no
tienen otros sistemas de monitorizacin, ni siquiera los mejores programas comerciales.
Como principales caractersticas podemos destacar:
Administracin completamente web.

Escalabilidad. Probado hasta 10.000 dispositivos.
Posibilidad de monitorizar redes internas y externas.
Sistema de alertas (email, SMS)
Creacin de plantillas de configuracin exportables/importables.
Autodescubrimiento de dispositivos.
Multiplataforma (Windows, Linux, AIX, Solaris)
Base de datos (Oracle, MySQL, PostgreSQL o SQLite).
Pgina 21 de 135
3.10.4 Centreon
Centreon es un software libre para el seguimiento y supervisin de la red basada en la

informacin de la herramienta de monitorizacin Nagios.
Centreon ofrece una interfaz simplificada para hacer el sistema accesible a un mayor
nmero de usuarios, incluidos los de carcter no tcnico, en especial con los grficos.
Los tcnicos, sin embargo, siempre tienen acceso a la informacin tcnica en Nagios.
Con Centreon podemos configurar Nagios sin meternos dentro de los archivos de
configuracin, pudiendo configurar Nagios de una forma sencilla.
Caractersticas
Una interfaz multi-usuario intuitiva y personalizable

Gestin de todos los archivos de configuracin de Nagios (CGI, nagios.cfg
...)
Una configuracin de mdulo de carga de Nagios
Compatibilidad Nagios 1.x, 2.x Nagios, Nagios 3.x
Prueba de la validez de la configuracin con el depurador de Nagios
Representaciones grficas personalizadas de los recursos monitorizados
Librera de plugins para comprobaciones bsicas por SNMP
Sistema de plantillas para host, servicios
3.10.5 FAN (Full Automated Nagios)
FAN es una plataforma de monitorizacin libre que engloba a varios software de

monitorizacin (Centreon, Nagios, NagVis)
El propsito de la herramienta FAN es proporcionar una instalacin rpida y fcil, que

incluye las herramientas ms utilizadas en la comunidad Nagios.
FAN est basado en CentOS, los programas que incluye son los siguientes:
Nagios: Aplicacin central de monitoreo

Nagios plugins: plugins para controlar diferentes equipos
Centreon: Interfaz web para Nagios
NagVis: asignacin avanzada (geogrfica, funcional, de servicios)
NDOUTILS: almacena los datos de Nagios en una base de datos MySQL
Caractersticas de FAN:
Una nica ISO que contiene el sistema operativo y la aplicacin Nagios

Basado en CentOS
Las herramientas estn configuradas automticamente.
Pgina 22 de 135
Fan es de libre distribucin.

Actualizaciones peridicas de FAN.
3.10.6 Anlisis y seleccin de la herramienta de monitorizacin
Aunque hay muchas ms alternativas de software para la monitorizacin de una red, nos
hemos centrado solo en estas 5 soluciones ya que son las ms utilizadas, concretamente
Nagios es la herramienta ms utilizada y por lo tanto de la que ms informacin y ayuda
podemos obtener.
En cuanto a las caractersticas tcnicas todas las opciones son similares, destacando
Centreon por su interfaz Web, amigable y sencilla de manejar, y su sistema de
plantillas, con el que crearemos plantillas para los host y servicios, ahorrndonos trabajo
y teniendo una clasificacin de los Host y servicios por las plantillas, adems de que
utiliza a Nagios como ncleo para la monitorizacin.
Dado que somos nuevos en la utilizacin de software de monitorizacin creemos que la

eleccin ms razonable es la que nos ayude a realizar el trabajo y nos d el soporte
necesario, por ello la eleccin ms conveniente es FAN, ya que engloba a Centreon y
Nagios, adems de una tercera herramienta, NagVis, con la que realizar mapas de red.
Con FAN no tendremos problemas de conectividad y compatibilidad entre las distintas
herramientas, ya que con su sistema de instalacin nos las prepara para trabajar desde el
primer instante, adems de que con sus actualizaciones peridicas podremos tener
siempre las ltimas versiones del software.
Con FAN tambin tenemos la ventaja de que no solo tendremos la ayuda y guas que
podamos encontrar en la comunidad de Nagios, sino que tambin podremos utilizar las
de Centreon y las de FAN las cuales son comunidades muy vivas.
Adems de todo lo anterior contamos con que FAN y las herramientas que lo forman
son OpenSource.
Pgina 23 de 135
4 Arquitectura de la plataforma de monitorizacin

El sistema a monitorizar consta de 2 partes, comunicaciones y sistemas. Planteamos las
siguientes alternativas para la arquitectura del sistema:
Instalacin Centralizada: Podemos tener distintos usuarios que tengan

distintos permisos de acceso a servicios y Host. Podemos realizar una
instalacin centralizada, donde tendremos toda la monitorizacin y distintos
usuarios que accedern a la parte correspondiente de la misma ya sea de
comunicaciones o de sistemas.
Instalacin distribuida: Podemos realizar la instalacin de la monitorizacin
de forma distribuida, es decir, tener varios sistemas de monitorizacin, uno para
la parte de comunicaciones y otro para la parte de sistemas.
Dado que hemos decidido trabajar con FAN Nagios, esta nos da las siguientes
alternativas
Sistema centralizado:
o Un Centreon con un Nagios, alojado todo en el mismo servidor.
Sistema distribuido:
o Un Centreon con mltiples instancias de Nagios, esto hace que
tengamos varios servidores, uno por cada instancia o poller de
Nagios.
Monitorizacin centralizada
Ventajas:
Bajo coste en hardware, solo tendremos un servidor.

Sin problemas de comunicacin entre las distintas instancias de monitorizacin,
ya que solo tendremos una.
Proceso de backup fcil de realizar, al tener todos los archivos de configuracin
juntos.
Inconvenientes:
Si la maquina falla toda la monitorizacin se para.

No se puede separar configuraciones, si en un futuro se quiere realizar una
arquitectura distribuida, esta se ha de empezar de cero.
Pgina 24 de 135
Monitorizacin distribuida
Ventajas:
Tendremos dos configuraciones de Nagios separadas, fciles de exportar, y en

caso de fallo, solo se dejara de monitorizar una parte y no toda la
monitorizacin.
Menos carga de trabajo para el servidor, ya que tendremos 2 servidores
trabajando.
Inconvenientes:
Mayor coste en hardware, tenemos que tener dos servidores,
Pgina 25 de 135
La opcin ms beneficiosa para nosotros es la de una arquitectura distribuida por ello

es la queremos realizar, pero para ello necesitamos tener 2 servidores mnimo, y dado
que nuestros recursos actualmente solo nos permiten disponer de solo un servidor,
tendremos que realizar una arquitectura centraliza.
Si ms adelante disponemos de un segundo servidor se realizaran los cambios

necesarios para realizar una arquitectura distribuida.
Pgina 26 de 135
5 Anlisis del sistema de monitorizacin
5.1 Usuarios de la monitorizacin
El sistema de monitorizacin tendr diferentes usuarios, cada uno de ellos tendr tareas
distintas, por ellos se han de crear varios usuarios con permisos diferentes para acceder
al sistema de monitorizacin. Los usuarios identificados son los siguientes:
Administrador
Usuario supervisor de la monitorizacin
Centreon nos da la posibilidad de crear usuarios, dndoles permisos de acceso distintos

a cada uno.
El usuario administrador tendr acceso a todo el sistema de monitorizacin, pudiendo

cambiar la configuracin del sistema.
El resto de usuarios, sern supervisores de la monitorizacin, corresponden a personas

fsicas del servicio informtico, estos usuarios tendrn acceso solo a lo que necesiten del
sistema de monitorizacin.
Durante la realizacin del proyecto solo se han dado de alta los usuarios, una vez que
los usuarios empiecen a usar el sistema se les darn los permisos que necesiten, estos
permisos tendr que drselos el administrador mediante las opciones ACL de Centreon.
Pgina 27 de 135
5.2 Host de la monitorizacin
Los Host es el primer paso para implementar la monitorizacin, tenemos que obtener la
lista de Host para aadirla en Centreon.
La lista de Host tenemos varias opciones de obtenerla:
La lista nos la da el administrador de red

Haciendo una consulta al DHCP
Haciendo una consulta SNMP
Una vez obtenida la lista tendremos que identificar los modelos de los equipos y sus
nombres, para as poder crear las plantillas que les asignaremos en la configuracin de
Centreon.
Crearemos una plantilla general, donde tendremos todos los datos posibles definidos
(Tiempo de chequeo, intentos mximos antes de enviar alertas, das que se mandan
alertas), y de ella heredarn todas las dems plantillas, as solo tendremos que ponerle
el dato especfico en cada una, el servicio bsico que queremos ponerle, el nombre y la
descripcin del objeto.
Listado de plantillas de host para Comunicaciones y Sistemas:
Nombre de la plantilla Alias

AP_1100 Punto de acceso Cisco 1100
AP_1140 Punto de acceso Cisco 1140
AP_1200 Enlace Cisco 1200
C3020_Blade Switch Cisco Eth 3020 Blade
C812_ Blade Switch Cisco FC 9124 Blade
Cabina_Discos_Hitachi Cabina Discos Hitachi
Controladora_Hitachi Controladora Hitachi
Controladora_Netapp_FASS_3020 Controladora Netapp FASS 3020
Pgina 28 de 135
Controladora_Netapp_FASS_3140 Controladora Netapp FASS 3140

DNS Servidor DNS
Firewall Firewall
Libreria_bauckup Libreria backup
Nodo_ESXi Nodo ESXi Vmware
Servidor_Hosting Servidor Hosting
SVR_linux Servidor linux
SVR_Windows Servidor Windows
Switch_2900 Switch Cisco Eth 2900
VC_Blade Virtual Connect Blade
SVR_Linux SVR Linux
SVR_Windows SVR Windows
Grupos de Host
Los grupos en la monitorizacin se crean en funcin de dos clasificaciones distintas,

una por tipo de servidor, y otra por localizacin del servidor, los servidores pueden
pertenecer a uno o varios grupos de estas clasificaciones.
La clasificacin por tipo de servidor, no es una clasificacin por tipos propiamente

dicha, ya que no solo miramos qu servidor es, sino que tambin se clasifican segn a
qu red pertenece o qu sistema operativo contiene, dependiendo de lo que nos interese
destacar. Segn este criterio nos salen los siguientes grupos:
Red_cableada : grupo para los equipos de la red por cable

Red_Inalambrica :grupo para los equipos con red WI-FI
Red_SAN : grupo para los equipo de la red de almacenamiento SAN
SVR_Linux : Servidores con sistema operativo Linux
SVR_Windows: Servidores con sistema operativo Windows
VMWARE : Mquinas virtuales
VMWARE_Servers: Servidores con sistema operativo VMWare ESX y ESXi
Firewall : Firewalls de la red
NAS: Servidores de la red de sistemas NAS
En la clasificacin por localizacin tenemos que ver de forma rpida en donde se

encuentran los equipos a monitorizar, esta clasificacin concuerda con los distintos
edificios del campus de la universidad, dndonos los siguientes grupos:
AMP: Ampliacin de politcnico

BIB: Biblioteca
CCT-ATR: Cct-Atrio
CCT-AUL: Cct_Aulario
CCT-ITA: ITA
Pgina 29 de 135
CCT-QMC: Qumicas
DEP: Departamental
FIL: Filologas
FUR: fundacin de la UR
PLD: Polideportivo
PLT: Politcnico
QUI: Quintiliano
RECT: Rectorado
VIV: Vives
Adems de los grupos anteriores, de la monitorizacin de Sistemas que tenan

previamente nos da los siguientes grupos, los cuales sern reutilizados:
NOMBRE DEL HOSTGROUP ALIAS

VMWare_Servers Servidores VMWare ESX y ESXi
MyAU Equipos de MyAU
RedIris Equipos en RedIris e Internet
DNS Servidores DNS
DHCP Servidores DHCP
Radius-WiFi Servidores Radius y Nocat para WiFi
Firewalls Firewalls
Correo Equipos y servicios de correo
Proxy-Web Servidores Proxy Web
web-servers-balanceados Servidores Web
LDAP Servidores LDAP
SysLog Servidores SysLog
TomCat Servidores TomCat
Citrix Servidores Citrix
certificados_ssl Certificados SSL para acceso Web
Backup Backup
Fund. Dialnet Fundacion Dialnet
Fund. UR Fundacion UR
Balanceados DMZ Balanceados en DMZ
Balanceados SVR Balanceados en Servidores
syslog-servers Servidores de Syslog
oracle-servers Servidores de BBDD de Oracle
tomcat-servers Servidores Tomcat
web-servers Servidores Web
ae-servers Servidores AE
5.3 Servicios de la monitorizacin
Cada uno de los Host que hemos identificado anteriormente tendr un conjunto de
servicios asociados con los que monitorizaremos sus recursos.
Pgina 30 de 135
Estos servicios tienen un comando asociado el cual es el encargado de recopilar la

informacin requerida para la monitorizacin, para nosotros ser el encargado de
realizar las consultas SNMP al Host.
Al igual que con los Host, tambin crearemos una serie de plantillas para los servicios
para clasificarlos y diferenciarlos de forma rpida. Estas plantillas tendrn asociado un
plugin o comando que ser el encargado de recoger la informacin del recurso a
monitorizar.
Plantillas de servicios para Comunicaciones:
NOMBRE DEL LA PLANTILLA COMANDO

UR_CPU_NETAPP UR_check_cpu_netapp
UR_CPU_WINDOWS UR_check_centreon_cpu
UR_DISK_FIREWALL UR_check_disk_firewall
UR_DISK_LINUX UR_check_disk_linux
UR_DISK_NETAPP R_ceck_disk_netapp
UR_DISK_WINDOWS UR_check_centreon_remote_storage
UR_PING UR_checl_ping
UR_LOAD_LINUX UR_check_load_linux
UR_MEMORY_LINUX UR_check_memory
UR_MEMORY_WINDOWS UR_check_centreon_memory
UR_SNMP_UPTIME UR_check_snmp_nowarn_nocrit
UR_SNMP_IFSTATUS_CISCO UR_check_snmp_ifstatus
UR_RADIO_CISCO UR_check_radio
Plantillas de servicios para Sistemas:
NOMBRE DE LA PLANTILLA COMANDO

UR_HTTP UR_Check_http
UR_HTTPS UR_Check_https
UR_CERT UR_check_cert
UR_ORACLE_LOGUIN UR_check_oracle_loguin
UR_CONNECTION_FIREWALL UR_check_connections
UR_TUNEL_DIALNET UR_check_tunnel_dialnet
UR_PROCESS UR_check_snmp_process
UR_POP3S UR_check_pop3_account
Pgina 31 de 135
UR_TCP UR_check_tcp
UR_SMTP UR_check_smtp
UR_SMTP_SEND UR_check_smtp_send
UR_SSMTP_SEND UR_check_ssmtp_send
UR_DNS UR_check_dns
UR_IMAP UR_check_imap
UR_FTP UR_check_ftp
UR_VIRTUAL_HOST UR_check_vhost
Para poder realizar estos servicios en cada Host necesitamos los siguientes datos:
Identificar qu recurso se quiere monitorizar.

Definir los valores crticos (Warning, Critical) del recurso, en caso de tenerlos.
El identificador de objeto (OID) del recurso.
5.3.1 Identificacin de recurso a monitorizar
Los recursos a monitorizar para la monitorizacin de Comunicaciones son los

siguientes:
Ping: este servicio es el bsico que se ha de encontrar en la plantilla

HOST_GENERAL y el cual han de tener todos los Host, con l veremos si el
Host es alcanzable.
Uptime: Este servicio es el servicio bsico de SNMP, este servicio lo tendrn
todos los host, con l veremos el tiempo que lleva activo el sistema.
Carga del sistema (CPU carga): La carga del sistema trata de medir la relacin
entre la demanda de trabajo y el realizado por el sistema, sta la tenemos que
poder ver en 1, 5 y 15 minutos.
Uso de CPU: Con este servicio veremos el porcentaje de uso de la CPU del
sistema.
Memoria RAM: Porcentaje de uso de la memoria RAM del sistema.
Memoria virtual (SWAP): Porcentaje de uso de la memoria SWAP del sistema.
Disco (particiones): Porcentaje de espacio de disco o particin libre.
Puertos Ethernet: En los puertos Ethernet son varias cosas las que nos interesa
monitorizar:
o Ver si la interfaz esta operativa.
o Ver si la interfaz es capaz de realizar un enlace.
o Ver el trfico del puerto Ethernet.
Los recursos a monitorizar para la monitorizacin de Sistemas son los siguientes:
Acceso a Web por http y https.

Caducidad de certificados.
Chequeo de cuentas de correo.
Servicio NTP.
Conexiones TCP.
Pgina 32 de 135
Estado de BD de Oracle.
Disponibilidad de las particiones de disco.
Estado de Host virtuales.
Para todos estos recursos se crearn servicios con los cuales chequear el estado del
recurso.
5.3.2 Definicin de los valores crticos (Warning, Critical) del

recurso
Cada servicio tiene unos valores de criticidad con los cuales al ser alcanzados o
sobrepasados generarn unas notificaciones que sern mandadas va correo electrnico
al responsable del recurso.
Estos valores los definimos en las reuniones junto con el responsable del Servicio
informtico de la UR, utilizaremos los valores de la siguiente tabla por defecto. Una vez
tengamos todos los servicios identificados y puestos en Centreon ser el responsable del
sistema de monitorizacin quien fije estos valores. Esto se debe a que cada servicio
tendr unos valores distintos, aunque por el momento pondremos unos valores por
defecto que utilizaremos en los servicios.
Para la monitorizacin de Comunicaciones tenemos los siguientes valores:
SERVICIO WARNING CRITICAL

Ping Prdida del 0.79% Prdida del 0.99%
Carga CPU Uso del 2% Uso del 5%
Memoria RAM Uso del 99% Uso del 100%
Memoria SWAP Uso del 10% Uso del 25%
Disco duro Uso del 75% Uso del 90%
Interfaz administrativa --- ---
Interfaz operacional --- ---
Trafico de red Uso del 50% Uso del 70%
Por la parte de Sistemas tenemos los siguientes valores:
SERVICIO WARNING CRTICAL

UR_HTTP Tiempo de respuesta No se establece
alto (10 segundos) conexin
UR_HTTPS Tiempo de respuesta No se establece
UR_CERT 1 da para expirar el Certificado expirado
certificado
UR_ORACLE_LOGUIN ------- No se establece
conexin
UR_CONNECTION_FIREWALL 94% de conexiones 97% de conexiones
UR_TUNEL_DIALNET ------- No hay conexin
UR_PROCESS ------- Proceso no existe
UR_POP3S 10 correos 50 correos
Pgina 33 de 135
UR_TCP ------- Sin conexin tras 10

segundos
UR_SMTP Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_SMTP_SEND Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_SSMTP_SEND Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_DNS ------ El DNS no responde
UR_IMAP ------ No responde
UR_FTP ------- No hay conexin
UR_VIRTUAL_HOST Tiempo de respuesta El servidor no escucha
alto en el puerto
5.3.3 El identificador de objeto (OID) de los recursos
Para la monitorizacin de estos recursos por SNMP es necesario obtener los OID
correspondientes para cada recurso, estos OID se encuentran en la MIB del sistema.
Dependiendo del recurso a monitorizar, el dispositivo y el fabricante del mismo la MIB
donde buscar cambia, por lo que nos tenemos que ver la documentacin del fabricante
para saber en qu MIB buscar.
Para buscar el OID tenemos dos opciones
Usar un MIBs Browser (buscador de MIB).

Realizar una bsqueda manual.
Si usamos un MIBs Browser tendremos que cargar la MIB donde est el OID que
queremos para realizar la bsqueda.
Si realizamos la bsqueda manualmente, tendremos que explorar la MIB e ir viendo

todas las entradas hasta encontrar la que buscamos.
Nosotros utilizaremos un programa para explorar la MIB y buscar manualmente el OID

que queremos, esto se debe a que los buscadores de MIB son programas de pago, y por
lo tanto no tenemos acceso a ellos, por ello utilizaremos un explorador de MIB y nos
valdremos de la informacin del fabricante y de Internet para encontrar los OID que
queremos.
Pgina 34 de 135
Los OID que utilizaremos se vern en el apartado de la implementacin de los plugins.
5.4 Servicios para Windows
Como se ha dicho anteriormente, los servidores pueden tener el sistema operativo Linux
o Windows. Todos los anteriores han sido para Linux. En caso de llevar Windows los
servicios realizados anteriormente no nos sirven, ya que los OID de los recursos a
monitorizar son distintos en Windows.
Para realizar la monitorizacin de los recursos de Windows tenemos 2 opciones:
Realizarlas mediante NRPE

Realizarlas mediante SNMP
Los comandos NRPE en Windows necesitan de los siguientes elementos para funcionar:
Pgina 35 de 135
El comando en el servidor de monitorizacin.

Un agente en el servidor a monitorizar para visualizar el recurso y devolver el
resultado al servidor de monitorizacin.
La solucin sera utilizar la herramienta NSClient++, con ella podramos realizar

consultar NRPE al servidor Windows. Solo es necesario instalar el agente en el servidor
Windows, y utilizar el comando check_nt para preguntar por el recurso que queramos.
Los comandos SNMP en Windows funcionan igual que en Linux, para utilizarlos se
siguen los mismos pasos:
Habilitar en el servidor Windows el SNMP y configurarlo.

Buscar los OID de los recursos a monitorizar.
Realizar los script para realizar las consultas SNMP.
Dado que uno de los puntos en el proyecto es el de cambiar el protocolo NRPE a

SNMP, para los servicios Windows realizaremos la monitorizacin de los recursos
mediante SNMP.
Los servicios a monitorizar en Windows son los siguientes:
Memoria RAM
Espacio de disco duro disponible
Conectividad
NTP
Procesos de Windows
Para realizar estos servicios utilizaremos los comandos que vienen por defecto en
Centreon ya que para los recursos que queremos monitorizar son suficientes.
Para cada servicio se le crear una plantilla que heredar de SERVICE_GENERAL.
Los comandos y plantillas a utilizar sern los siguientes:
Pgina 36 de 135
PLANTILLA COMANDO
UR_check_centreon_cpu check_centreon_snmp_cpu
UR_check_centreon_remote_storage check_centreon_snmp_remote_storage
UR_check_centreon_memory check_centreon_snmp_memory
UR_check_centreon_process_exists check_centreon_snmp_process
5.5 Plugins de la monitorizacin
Los plugins son los comandos (scripts) que utilizan los servicios para obtener los datos
de monitorizacin, por lo tanto tendremos que crear comandos para la monitorizacin
del sistema.
Estos plugins tenemos varias formas de obtenerlos:
Utilizar comandos de la antigua configuracin.

Utilizar comandos que vienen con Centreon por defecto.
Buscar en Internet los plugins que nos puedan servir.
Realizar nosotros los comandos.
Reutilizacin de comandos
El servicio informtico de la UR ya utilizaba previamente una monitorizacin de

Comunicaciones y Sistemas, por lo tanto tendr comandos que podremos reutilizar.
Estos comandos sern aquellos que no usen el protocolo NRPE, estos comandos sern
por ejemplo, los que chequean webs, bases de datos, acceso a ftp
Los comandos que reutilizaremos sern para la monitorizacin de Sistemas y sern los
siguientes:
Check_http
Check_oracle
Check_pop
Check_tcp
Check_smtp
Check_smtp_send
Check_dns
Check_imap
Check_ntp
Check_ftp
Comandos de Centreon
Centreon nos viene con una serie de comandos definidos que se pueden utilizar, estos
comandos los utilizaremos para los servicios Windows. Esta decisin se basa en que los
Pgina 37 de 135
comandos que nos da Centreon cumplen nuestras expectativas para los recursos de
Windows, y por lo tanto no es necesario realizar nuevos comandos.
Los comandos utilizados son los siguientes:
Check_centreon_snmp_cpu
Check_centreon_snmp_remote_storage
Check_centreon_snmp_memory
Check_centreon_snmp_process
Repositorios de Plugins en Internet
Hay plugins, que por su gran utilidad los podemos encontrar fcilmente en Internet,
concretamente en pginas especializadas en plugins para Nagios, donde los usuarios
suben sus propias creaciones, o donde estn los plugins oficiales de Nagios.
Los plugins que se han buscado por Internet son los siguientes:
check_snmp_ifstatus.pl: este comando nos da la informacin de un Puerto

Ethernet (trfico, estado,)
check_pop3_account: este comando se usaba previamente, se ha bajado la ltima
versin y se ha reutilizado, nos da la informacin de una cuenta de correo
(correo en la bandeja de entrada)
Comandos nuevos
La mayora de plugins los crearemos nosotros, para ello tendremos que saber qu es lo
que queremos consultar va SNMP, buscar el OID correcto en la MIB y tratar el dato
para adecuarlo y que as Centreon pueda trabajar con l.
Comandos realizados para Comunicaciones:
UR_check_load_linux
UR_check_cpu_netapp
UR_check_disk_firewall
UR_check_disk_linux
UR_check_disk_netapp
UR_check_memory
UR_check_ethernet
UR_check_radio
Comandos realizados para Sistemas:
UR_check_cert
UR_check_connections
UR_check_tunnel_dialnet
UR_check_virtual_host
Diagrama de actividad general
Pgina 38 de 135
En el siguiente diagrama de actividad, se muestra la actividad general que tendrn

todos los scripts, comprobacin de parmetros de entrada, consulta SNMP,
procesamiento del dato y envo del resultado.
Resumen Visin general de los script

Actor principal Sistema de monitorizacin
Precondicin Realizacin de chequeo automtico , o
forzado
Postcondicin Se realiza el chequeo del recurso
Flujo bsico -Se comprueba parmetros de entrada
-Se realiza la consulta SNMP
-Se procesa el dato obtenido y se devuelve
el resultado
Flujo alternativo Alguno de los parmetros introducidos es
errneo o se produce algn error en la
consulta SNMP y se devuelve un mensaje
de error.
Pgina 39 de 135
ad: Diagrama_general
Sof tware de Monitorizacin Script (addon) de monitorizacin
Inicio
Introducir parametros de entrada Comprobar parametros de entrada
Env iar error
Parametros correctos?
Consulta SN MP
NO
Consulta SN MP correcta?
SI
Procesamiento del dato SNMP
Env iar estado del recurso
Presentar resultado de monitorizacin
El dato devuelto a Centreon tiene que tener un formato determinado para que ste pueda
ser interpretado para asignarle un color a su estado y dibujar las grficas. Esto se har en
el cdigo de cada script antes de devolver el dato.
El formato que se ha de enviar tiene que ser el siguiente:
Pgina 40 de 135
(user_readable_message_for_nagios) | (label)=(value)(metric);(warn level);(crit

level);(min level);(max level)
El primer valor es para Nagios, seguido de una tubera y el formato para Centreon, una
etiqueta para que el valor tenga nombre, seguido del valor del dato y su mtrica (la
mtrica se puede omitir), el resto de valores como crtico, valor mximo o mnimo, se
pueden omitir. Una vez en Centreon podemos ajustar los parmetros aqu omitidos para
ver los grficos que queremos.
UR_check_virtual_host
Con este comando se ha de chequear el estado de las pginas Web alojadas en un

servidor con Host virtuales.
Estas pginas web se encuentran por duplicado detrs de un servidor de balanceo, a la

hora de monitorizar estas web, desde nuestro servidor de monitorizacin, solo somos
capaces de ver el servidor de balanceo y comprobar ah el estado de la pgina web.
Dado que lo que queremos es ver el estado de la web en los host virtuales y no el que
nos muestra el servidor de balanceo, tendremos que buscar una solucin para poder
realizar una monitorizacin de los host virtuales.
La solucin que implantaremos ser crear un nuevo OID en el servidor de balanceo, el

cual, haciendo una consulta SNMP desde nuestro servidor de monitorizacin, nos dar
el estado de los host virtuales.
Pgina 41 de 135
Este servicio es distinto al resto, se diferencia en que el recurso que queremos

monitorizar no se encuentra en ninguna MIB, y por lo tanto, para realizar una consulta
SNMP para monitorizar el recurso tendremos que crear nuestro propio OID y aadirlo
al servidor para as realizar la consulta SNMP.
Utilizaremos una rama de la MIB en la que se puedan aadir OID propios, para nuestro
caso utilizaremos el siguiente OID .1.3.6.1.4.1.2021.* y dentro de esta rama a partir del
120, ya que los anteriores estn siendo utilizados.
Para la monitorizacin de los host virtuales realizaremos los siguientes pasos:
Realizar script para servidor balanceado: Con este script realizaremos el chequeo
de la web en el host virtual.
Realizar script para Centreon: El script alojado en Centreon realizara una
consulta SNMP al servidor balanceado preguntando por el OID correspondiente
al host virtual que queramos chequear.
Configuracin del archivo snmp.conf en el servidor balanceado.
5.6 Eleccin de servidor de correo
Nuestro sistema de monitorizacin tiene que mandar alertas a los responsables de los
recursos cuando se produce una incidencia. Para mandar estas alertas tenemos que
elegir un servidor de correo para que mande un email con la incidencia.
Cuando instalamos FAN por defecto nos viene instalado Sendmail, un servidor de
correo de cdigo abierto.
Sendmail nos sirve perfectamente para mandar las alertas por correo electrnico, pero
Sendmail funciona con el usuario root, y si se tiene cualquier vulnerabilidad, se puede
comprometer el sistema, por ello buscamos otra alternativa a Sendmail.
Investigando en Internet, y foros para informarnos sobre servidores de correo, vemos

que la mejor alternativa a Sendmail es Postfix, esto se debe a que Postfix es un software
libre, fcil de configurar y de los ms seguros y adems ya est siendo utilizado en el
Servicio Informtico para otros usos, con lo cual se conoce esta tecnologa.
Dado que nuestro servidor de monitorizacin va a tener conexin con todos los
servidores del CPD, la seguridad es algo muy importante, y por ello, creemos que
Postfix es la mejor eleccin como servidor de correo.
5.7 Comunicacin y permisos con servidores
Dado que el servidor de monitorizacin tiene que tener acceso a todos los servidores
que se quieren monitorizar tendremos que darle permisos en los firewall que necesite
Pgina 42 de 135
para acceder a la red de comunicaciones. Estos permisos los tiene que dar el
administrador de seguridad.
Tambin nos ha de dar permisos a mi equipo personal para poder acceder a la interfaz
Web de Centreon y Nagios y as poder trabajar con ellas.
5.8 Copia de Seguridad del sistema
Durante las reuniones de seguimiento se solicit la necesidad de realizar una copia de

seguridad de la configuracin de la herramienta de monitorizacin tanto para
Comunicaciones como para Sistemas.
Para resolver este punto se barajaron varias opciones:
Aadir el servidor de monitorizacin al sistema de backup que se tiene en

el Servicio Informtico.
Realizar una mejora en la pgina web de la herramienta de
monitorizacin para realizar la copia de seguridad.
Si realizbamos la primera opcin todo el servidor sera copiado, y aunque es una

solucin es ms de lo que necesitamos, ya que no solo se guardara la configuracin
sino tambin todo el resto de datos que tiene el servidor y que no nos interesa guardar.
Si se elige la segunda opcin tendramos que realizar la copia de seguridad en la web, y

sta se guardara en el servidor de monitorizacin, tenindola que sacar de ah y
guardndola en otro sitio, ya sea disco u otro servidor.
Como solucin se decidi realizar una mezcla de ambas opciones, se realizar la copia
de seguridad de los archivos de configuracin de Nagios, Centreon y NagVis mediante
la pgina web, y se guardarn en un archivo comprimido en un directorio del servidor
de monitorizacin, y el servicio de backup del Servicio Informtico ser el encargado de
integrar esos datos dentro de la poltica de backup corporativa.
Las BBDD donde se guardan los datos de la monitorizacin son muy grandes, por ello,
por el momento no se van a realizar copias de seguridad de las BBDD. En un futuro se
buscara implantar un sistema para realizar el backup de las BBDD como la
deduplicacin.
Por lo tanto nosotros solo tenemos que realizar la copia de seguridad mediante la pgina
Web y guardarla en un directorio del servidor de monitorizacin, del resto se encargara
la herramienta de backup del servicio informtico.
Los archivos de configuracin que tenemos que guardar son los de Nagios, ya que ah
est toda la configuracin de host, servicios, plantillas los mapas de Nagvis y la
configuracin de Centreon, donde tenemos los usuarios y la configuracin de los
poller.
Pgina 43 de 135
Para ellos realizaremos una modificacin en la Web de Fan Nagios, poniendo un enlace
que nos llevar a una nueva pgina donde podremos hacer la copia de seguridad.
Pgina 44 de 135
6 Implementacin del sistema de monitorizacin en

Comunicaciones
6.1 Implementacin de Host
6.1.1 Lista de equipos a monitorizar
La lista de equipos a monitorizar en la red de comunicaciones es una lista consistente,

no se dan equipos de alta y baja con relativa rapidez. Cuando hay algn cambio lo
normal suele ser dar de alta o baja un punto de acceso. Por ello una vez identificada toda
la lista de equipos esta cambiara poco a lo largo del tiempo de la vida del proyecto.
Para sacar la lista de equipos usaremos la informacin que ya tenamos de la

configuracin previa de Nagios en el archivo host.cfg, aunque esto es una pequea
parte, el resto lo tendremos que sacar con las listas que nos d el responsable del sistema
informtico consistente en una relacin de IPs de varias redes de clase C.
Con esta lista de quipos hemos de sacar sus nombres para poder identificarlos y
aadirlos a la monitorizacin. Para ello utilizaremos comandos SNMP, realizaremos
una consulta SNMP en la que preguntaremos el nombre del equipo y el modelo. Para
realizar esta consulta hemos realizado un pequeo script (snmpName.sh) con el que
lanzaremos la consulta a toda la red para as tener todos los nombres de los equipos,
tanto los que estn en la lista como los que no estn. Adems de esta forma sabremos en
qu equipos se encuentra activo el SNMP.
Para realizar la consulta tenemos que saber el identificador de objeto de la MIB por el
que hemos de preguntar. En este caso el identificador es sysName. Para buscar este
identificador de objeto utilizaremos motores de bsqueda de MIB, bsquedas en Google
o en documentacin del equipo.
En este caso sysName es una variable que se encuentra en el grupo System que tienen
todos los equipos con SNMP.
Este script tambin lo ejecutaremos para otras redes que pertenecen a la infraestructura
de comunicaciones, con esto obtendremos todos los equipos pertenecientes a la red de
comunicaciones, su IP con su nombre (modelo) de equipo.
6.1.2 Plantillas y grupos de host
La plantilla de HOST_GENERAL quedar de la siguiente forma:
1. Host Template Name: HOST_GENERAL

2. Alias: HOST GENERAL
3. IP addres: Valor en blanco
Pgina 45 de 135
4. SNMP community: Valor en blanco

5. Multiples plantillas: Valor en blanco
Propiedades de chequeo del Host
1. Check Period: 24x7

2. Check Command: check_ping
3. Args: !3000.0,79%!5000.0.00%!1 ( los argumentos se definen con ! por
delante de cada argumento)
4. Max Check Attempts: 5
5. Normal Check Interval: 10
6. Retry Check Interval: Valor por defecto
7. Active Checks Enable: Valor por defecto
8. Passive Checks Enable: Valor por defecto
Notificaciones
1. Notification Enable: No
2. Linked Contacts: Valor en blanco
3. Linked Contact Groups: Valor en blanco
4. Notification Intervar: 120
5. Notification Period: 24x7
6. Notification Options: Valor por defecto
7. First notification delay: 1
Pgina 46 de 135
Relaciones
Linked Service Templates: Valor en blanco
Los valores que se dejan en blanco, o no hacen falta o son especficos de cada Host y se
rellanarn a medida que metamos los Host en la herramienta de monitorizacin.
6.1.3 Observaciones
Durante este apartado se han ido aadiendo equipos hasta llegar a los 166 equipos
monitorizados.
Cuando se han ido buscando los nombres y modelos de los equipos mediante las
consultas SNMP, tenamos que asegurarnos de que cuando esta no responda era porque
efectivamente no haba ningn equipo en esa direccin y no por que no tuviese el
servicio SNMP activado, para asegurarnos realizbamos la siguiente accin:
Se comprobaba la disponibilidad del equipo mediante el comando ping a las

direcciones que estaban en la lista y no respondan al SNMP, as nos
asegurbamos de que haba un equipo en la direccin IP y que haba que activar
el servicio SNMP.
6.2 Implementacin de servicios de Comunicaciones
6.2.1 Identificacin de recursos
Durante las reuniones de seguimiento, una vez obtenida la lista de host a monitorizar se
han planteado los siguientes recursos que han de ser monitorizados:
Pgina 47 de 135
Ping: este servicio es el bsico que se ha de encontrar en la plantilla

HOST_GENERAL y el cual han de tener todos los Host; con el veremos si el
Host es alcanzable.
Uptime: este servicio es el servicio bsico de SNMP, este servicio lo tendrn
todos los host, con el veremos el tiempo que lleva activo el sistema.
Carga del sistema (CPU carga): La carga del sistema trata de medir la relacin
entre la demanda de trabajo y el realizado por el sistema, sta la tenemos que
poder ver en 1, 5 y 15 minutos.
Uso de CPU: con este servicio veremos el porcentaje de uso de la CPU del
sistema.
Memoria RAM: porcentaje de uso de la memoria RAM del sistema.
Memoria virtual (SWAP): Porcentaje de uso de la memoria SWAP del sistema.
Disco (particiones): porcentaje de espacio de disco o particin libre.
Puertos Ethernet: en los puertos Ethernet son varias cosas las que nos interesa
mirar:
o Ver si la interfaz est operativa
o Ver si la interfaz es capaz de realizar un enlace
o Ver el trfico del puerto ethernet
6.2.2 Definicin de los valores crticos (Warning, Critical) de los

recursos
Cada servicio tiene unos valores de criticidad que al ser alcanzados o sobrepasados
debemos generar unas notificaciones que sern mandadas va correo electrnico al
responsable del recurso.
SERVICIO WARNING CRITICAL

Ping Prdida del 0.79% Prdida del 0.99%
Carga CPU Uso del 2% Uso del 5%
Memoria RAM Uso del 99% Uso del 100%
Memoria SWAP Uso del 10% Uso del 25%
Disco duro Uso del 75% Uso del 90%
Interfaz administrativa --- ---
Interfaz operacional --- ---
Trafico de red Uso del 50% Uso del 70%
Los datos aqu ofrecidos son los valores de criticidad por defecto, estos valores pueden
cambiar para determinados servicios.
Los valores de criticidad para los discos y particiones cambian para cada una, ya que
algunos, por el uso que se les da (bases de datos, backups,) no cambia mucho su
volumen.
Pgina 48 de 135
Los valores para los servicios de interfaz administrativa y operacional vienen dados por
la consulta SNMP, siendo estos 1, 2, 3 que corresponden con valores de error, ok y
crtico.
6.2.3 Identificador de objeto (OID)
Para la obtencin de los OID que necesitamos para monitorizar los recursos que
queremos ser necesario mirar la documentacin del fabricante de los dispositivos a
monitorear. El fabricante es CISCO, por lo tanto es en su documentacin donde tenemos
que buscar los OID que nos interesan.
En su pgina Web se encuentra un traductor donde podemos poner el recurso que

queremos monitorizar y nos devuelve el OID que le corresponde, con lo que ya
podemos obtener la informacin del recurso mediante SNMP.
En caso de que no tengamos el nombre exacto del recurso para obtenerlo en la

documentacin del fabricante, tendremos las dos posibilidades citadas anteriormente:
Usar un MIBs Browser (buscador de MIB)

Realizar una bsqueda manual
La solucin a utilizar ser realizar una bsqueda manual. Esta decisin se basa en que la
mayora de MIBs Browser no son software libre y los que lo son no cubren nuestras
necesidades, por lo que exploraremos la MIB e iremos buscando hasta dar con el dato
que necesitamos. Esta bsqueda es tediosa ya que hay que ir viendo todo el rbol hasta
dar con el dato que deseamos.
Pgina 49 de 135
6.2.4 Identificacin y descripcin de plantillas de servicios
Para las plantillas de servicios haremos lo mismo que en las plantillas de los host,
realizaremos un SERVICE_GENERAL donde pondremos todos los datos en comn de
los servicios.
La plantilla de SERVICE_GENERAL quedar de la siguiente forma
Informacin general
Pgina 50 de 135
1. Service Template Name: SERVICE_GENERAL

2. Alias: SERVICE GENERAL
3. Service template model: Valor en blanco
1. Is volatile: Valor por defecto

2. Check Period: 24x7
3. Check Command: Valor en blanco
4. Args: Valor en blanco
5. Max Check Attempts: 3
6. Normal Check Interval: 5
7. Retry Check Interval: 3
8. Active Checks Enable: Valor por defecto
9. Passive Checks Enable: Valor por defecto
Notificaciones
8. Notification Enable: No
9. Implied Contacts: Valor en blanco
10. Implied Contact Groups: Valor en blanco
11. Notification Intervar: 120
12. Notification Period: 24x7
13. Notification Options: Valor por defecto
14. First notification delay: 1
Pgina 51 de 135
Relaciones
Linked to host Templates: Valor en blanco
6.3 Implementacin de plugins comunicaciones
6.3.1 Comando UR_check_load_linux
Con este comando queremos ver la carga de CPU en 1,5 y 10 minutos. Para ello
tenemos que buscar en la MIB la parte correspondiente a estos datos y localizar sus
OID.
Los OID que corresponden para la carga son 1.3.6.1.4.1.2021.10.1.3, seguidos de .1 .2

.3 para los 1,5 y 10 minutos respectivamente. La MIB donde se encuentra este dato es
UCD-SNMP-MIB y el nombre al que responden estos OID son laLoad.
El comando quedara de la siguiente forma:
ur_check_load_linux.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$
$ARG1$: Community
$ARG2$: Tiempo de chequeo
$ARG3$: Valor warning
$ARG4$: Valor critico
Ejemplo:
ur_check_load_linux.sh $HOSTADDRESS$ community 1m 2 5
Pgina 52 de 135
LOAD 1m: 1.15 | LOAD_1m=1.15
6.3.2 Comando UR_check_cpu_netapp
Con este comando se chequea el tiempo de CPU de un dispositivo NetApp, los valores
obtenidos son porcentajes respecto al total. Una vez procesada la informacin el
resultado es un dato que Centreon es capaz de entender.
Los OID que corresponden al tiempo de CPU son el 1.3.6.1.4.1.789.1.2.1. En la MIB

SNMPv2-SMI, concretamente nos interesan el porcentaje que est en uso y el que no,
estos valores corresponden a nuestro OID seguido .3.0 y .5.0 respectivamente.
Una vez obtenidos el valor que queremos se formatear la salida para que Centreon
pueda entender el dato y se le mandar el resultado.
ur_check_cpu_netapp.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$
$ARG1$: Community
$ARG2$: Tiempo ocupado u ocioso (busy / idle)
Ejemplo:
ur_check_cpu_netapp.sh HOSTADDRESS community busy 80 90
CPU BUSY: 6% | CPU_BUSY=6
6.3.3 Comando Check_disk
Para el espacio en disco tenemos varios comandos distintos, esto se debe a que son
dispositivos distintos, y por lo tanto tienen diferentes MIBs y OID para los datos de
espacio en disco que necesitamos. Por ello se ha decidido hacer comandos distintos para
cada uno de ellos, as si se cambia de dispositivo o se aaden nuevos no se ha de ir
cambiando el script cada vez para que no d errores de compatibilidad con los OID.
6.3.4 Comando UR_check_disk_firewall
Con este script se chequea el espacio de disco de un Firewall, para este comando
necesitamos la particin que se quiere chequear y si es el espacio usado o el libre.
Pgina 53 de 135
La MIB que usamos es SNMPv2-SMI y el OID es 1.3.6.1.4.1.2620.1.6.7.6.1, al hacer

snmpwalk a este OID obtenemos el siguiente resultado
#snmpwalkv2ccadmmon10.254.0.2021.3.6.1.4.1.2620.1..1
SNMPv2SMI::enterprises.2620.1.6.7.6.1.1.1.0=Counter32:1
.
Con este resultado podemos comprobar las particiones de disco, el nmero de unidades,
su nombre, su capacidad de disco, el porcentaje de disco usado. Para nosotros el dato
importante es el porcentaje de disco usado que se encuentra en la rama .8, el resto de
datos tambin los usaremos en unos script auxiliares que usaremos para sacar los
nombres de las particiones de forma automtica, ya que no tenemos otra forma de
saberlas y son necesarias para nombrar a los servicios.
ur_check_disk_firewall.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$

$ARG5$
$ARG1$: Community
$ARG2$: Particin de disco
$ARG3$: Espacio usado o libre (used / free)
Ejemplo:
ur_check_disk_firewall.sh HOSTADDRESS community /var used 85 90
SPACE USED [/var]: 23% | PERCENTAGE_SPACE_USED_/var=23
6.3.5 Comando UR_check_disk_linux
Con este comando comprobaremos el espacio es disco de los servidores Linux la MIB
que se utiliza es UCD-SNMP-MIB y el OID que necesitaremos es 1.3.6.1.4.1.2021.9.1,
si realizamos un snmpwalk a ese OID obtendremos el siguiente resultado.
snmpwalkv2ccsoloread10.0.1.111.3.6.1.4.1.2021.9.1
UCDSNMPMIB::dskIndex.1=INTEGER:1
UCDSNMPMIB::dskPath.1=STRING:/
UCDSNMPMIB::dskPath.2=STRING:/proc
Pgina 54 de 135
UCDSNMPMIB::dskDevice.1=STRING:/dev/mapper/LVM01LogVol00
UCDSNMPMIB::dskDevice.2=STRING:proc
UCDSNMPMIB::dskMinimum.1=INTEGER:1
UCDSNMPMIB::dskMinimum.2=INTEGER:1
.
Todos estos datos estn relacionados con el espacio en disco, en esta caso tenemos 11
particiones (ya que el ndice va hasta el nmero 11), pero solo nos interesa una, para
ello tenemos que identificar el nmero que tiene asignado y recoger los datos
relacionados con l.
ur_check_disk_linux.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$

$ARG5$
$ARG1$: Community
Ejemplo:
ur_check_disk_linux.sh HOSTADDRESS community / used 85 90
SPACE USED [/]: 10.43% | SPACE_USED_/=2119024 SPACE_TOTAL_/=20314748
6.3.6 Comando UR_check_disk_netapp
En este comando comprobaremos el porcentaje de disco usado en un dispositivo

Netapp, la MIB donde se encuentran los datos a utilizar es SNMPv2-SMI y los OID que
necesitaremos sern los siguientes, el de descripcin de la particin, que nos da su
nombre y el de porcentaje de disco usado estos OID son 1.3.6.1.4.1.789.1.5.4.1.2 y
1.3.6.1.4.1.789.1.5.1.6 respectivamente.
ur_check_disk_netapp.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$

$ARG5$
$ARG1$: Community
Pgina 55 de 135
Ejemplo:
ur_check_disk_netapp.sh HOSTADRRESS comunity /vol/NAPPS/ used 85 90
SPACE USED [/vol/NAPPS/]: 58% | PERCENTAGE_SPACE_USED_/vol/NAPPS/=58
6.3.7 Comando UR_check_memory
Con este comando podremos obtener el porcentaje de memoria utilizada por el equipo,
tanto la memoria RAM como la SWAP, para ello utilizaremos la MIB UCD-SNMP-
MIB y el OID 1.3.6.1.4.1.2021.4.
Si hacemos snmpwalk a ese OID obtenemos el siguiente resultado
snmpwalkv2ccsoloread10.3.1.511.3.6.1.4.1.2021.4
UCDSNMPMIB::memIndex.0=INTEGER:0
UCDSNMPMIB::memErrorName.0=STRING:swap
UCDSNMPMIB::memTotalSwap.0=INTEGER:1052248
UCDSNMPMIB::memAvailSwap.0=INTEGER:1052164
UCDSNMPMIB::memTotalReal.0=INTEGER:2075560
UCDSNMPMIB::memAvailReal.0=INTEGER:268844
UCDSNMPMIB::memTotalFree.0=INTEGER:1321008
UCDSNMPMIB::memMinimumSwap.0=INTEGER:16000

Lo que haremos ser discriminar dependiendo si queremos RAM o SWAP y si

queremos la memoria usada o la libre.
ur_check_memory.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$

$ARG5$
$ARG1$: Community
$ARG2$: Memoria ram o Swap (ram / swap)
$ARG3$: Memoria libreo en uso (used / free)
Ejemplo:
ur_check_memory.sh HOSTADDRESS community ram used 75 90
RAM USED: 98.07% [TOTAL FREE 154MB]| RAM_USED=8089580

RAM_TOTAL=8248120
Pgina 56 de 135
6.3.8 Comando UR_check_ethernet
Con este comando chequeamos el estado de los puertos Ethernet en los AP, para ello
necesitaremos los siguientes datos, la descripcin o nombre del puerto, el estado
administrativo del puerto y el estado operacional del puerto, con ello sabremos si el
puerto es alcanzable y si responde.
La MIB donde se encuentran estos datos es IF-MIB y los OID que usaremos son los
siguientes 1.3.6.1.2.1.2.2.1.2 para el nombre 1.3.6.1.2.1.2.2.1.7 para el estado
administrativo y 1.3.6.1.2.1.2.2.1.8 para el estado operacional.
Si hacemos snmpwalk a los siguientes datos obtenemos estos resultados
snmpwalkv2ccadmmon10.254.0.241.3.6.1.2.1.2.2.1.2
IFMIB::ifDescr.1=STRING:Vlan1
IFMIB::ifDescr.99=STRING:Vlan99
IFMIB::ifDescr.5001=STRING:Portchannel1
IFMIB::ifDescr.10101=STRING:GigabitEthernet1/0/1
.
IFMIB::ifAdminStatus.1=INTEGER:up(1)
..
IFMIB::ifOperStatus.1=INTEGER:down(2)
IFMIB::ifOperStatus.99=INTEGER:up(1)
IFMIB::ifOperStatus.10101=INTEGER:down(2)
.
Pgina 57 de 135
Estas listas nos muestran los datos de todos los puertos del switch, se utilicen o no se
utilicen, por lo tanto hay que realizar una bsqueda del puerto en concreto que
queremos monitorizar.
ur_check_ethernet.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$
$ARG1$: Community
$ARG2$: Interfaz
$ARG3$: Estado (oper / admin)
Ejemplo:
ur_check_ethernet.sh HOSTADDRESS community GI2/0/26 oper
GI2/0/26 OPER STATUS: 1 UP | OPER_STATUS=1
6.3.9 Comando UR_check_radio
Al igual que con los puertos Ethernet con este comando monitorizaremos el estado de
los puertos Dot11radio0, para la red WiFi. La MIB que usaremos ser IF-MIB y el OID
que utilizaremos ser el 1.3.6.1.2.1.2.2.1, esto OID nos devolver una parte del rbol
donde tendremos los datos que nos interesan.
Realizaremos una discriminacin dependiendo si queremos el estado operacional o

administrativo, como con los puertos Ethernet, y devolveremos el valor formateado para
Centreon
ur_check_radio.sh $HOSTADDRESS$ $ARG1$ $ARG2$
$ARG1$: Community
$ARG2$:Estado (oper / admin)
Ejemplo:
ur_check_radio.sh HOSTADDRESS community oper
ADMIN STATUS: 1 UP | ADMIN_STATUS=1
Pgina 58 de 135
7 Implementacin de la monitorizacin de Sistemas

Una vez realizada la parte de comunicaciones se empezar a realizar la parte de
sistemas, donde tendremos que monitorizar no solo los servidores sino tambin
servicios que hay en ellos como pginas Web, bases de datos
Dado que de Sistemas ya exista una monitorizacin previa, reutilizaremos el material

que podamos para esta nueva monitorizacin con FAN. Vamos a coger los archivos de
configuracin antigua de Nagios (service.cfg, hosts.cfg, groups.cfg) y sacaremos la
informacin que podamos con ellos para utilizarla. Tengamos en cuenta que los
archivos de configuracin de la monitorizacin antigua de Nagios no podemos
utilizarlos sin ms en la nueva monitorizacin, aunque sea tambin Nagios, ya que han
de pasar a travs de Centreon, esto se debe a que el flujo de la informacin contenida en
los archivos de configuracin va de Centreon a Nagios y no de Nagios a Centreon.
7.1 Arquitectura de la monitorizacin Sistemas
Llegado a este punto donde se va a empezar a implementar la monitorizacin de

sistemas, se nos da el recurso necesario (un servidor) para realizar una arquitectura
distribuida.
Dado que ya tenemos montado un servidor con FAN con la monitorizacin de

comunicaciones, y no queremos rehacer el trabajo realizado hasta ahora, se vuelve a
estudiar las posibilidades que tenemos para realizar la monitorizacin de Sistemas.
Tenemos las siguientes opciones:
Pgina 59 de 135
1. Realizar la monitorizacin en un poller nuevo (Un servidor nuevo)

2. Alojarlo en una nueva herramienta FAN (Un servidor nuevo)
Cada una de estas opciones tienes sus pros y sus contras.
Para la primera opcin, realizar la monitorizacin en un poller nuevo:
Monitorizaciones separadas, tenemos una configuracin para cada

monitorizacin, en caso de fallo en el sistema solo afectar a la monitorizacin a
alojada en ese sistema.
Menos carga de trabajo para el servidor, ya que tenemos 2, uno por cada poller.
Mayor coste en material, ya que se necesita un nuevo servidor donde alojar el
poller con la monitorizacin nueva.
Para la segunda opcin, alojarlo en una nueva herramienta FAN:
Independencia total entre las monitorizaciones.

Tenemos FAN por duplicado, con el trabajo y coste que conlleva.
Con estas opciones, se decide realizar la primera, ya que vemos que es la opcin ms
satisfactoria, con ella podremos ver las 2 monitorizaciones desde la misma maquina con
la interfaz de Centreon, las configuraciones estarn separadas, por lo que los cambios
que se hagan solo afectarn a la configuracin de la monitorizacin a la que afectan y
ambas compartirn la misma base de datos.
Pgina 60 de 135
7.2 Instalacin del poller de Sistemas
Una vez se ha decidido por una monitorizacin distribuida vamos a instalarla en el

nuevo servidor. Para realizar una instalacin distribuida seguiremos los siguientes pasos
Instalar FAN Nagios como poller.

Configurar Centreon central para detectar el poller de Nagios
Las instrucciones para realizar estos pasos se encuentran en el manual de usuario.
7.3 Implementacin de Host en Sistemas
La monitorizacin de Sistemas, como ya se dijo anteriormente, ya estaba realizada, por

lo que parte del trabajo que se ha hecho ser reutilizado.
Pgina 61 de 135
Los Host de sistemas los podemos encontrar en la configuracin antigua de Nagios, en

el archivo host.cfg, as pues exploraremos el archivo e iremos sacando uno a uno los
nombres, la direccin IP y el grupo al que pertenecen.
Una vez tengamos esa lista, meteremos los datos con Centreon y se le indicar que
pertenecen al poller de Sistemas, concretamente nos salen 142 Host a monitorizar en la
parte de Sistemas.
Para aadir estos Hosts a Centreon, en lugar de aadirlos uno por uno y crendolos
nuevos como se hizo con Comunicaciones, utilizaremos la posibilidad que nos da
Centreon de cargar los hosts desde los archivos de configuracin de Nagios.
Cargar los host desde los archivos de configuracin tiene las siguientes ventajas:
Es la forma ms rpida de aadir nuevos Hosts, ya que cargaremos todos a la

vez.
Sin fallos de transcripcin, ya que no tenemos que meter datos manualmente.
Si alguno de los host introducidos de esta forma ya existiera, este no sufrira
cambios, y el mismo Centreon omitira el Host introducido.
Pero tambin hay que tener en cuenta varias cosas antes de cargar la configuracin:
Los Host tienen grupos asociados, si ese grupo no existe en nuestra lista de host
group tendremos un error y no nos dejar cargar los datos, por lo tanto
tendremos que cambiar los grupos que no tengamos por otros que s en los host,
antes de cargarlos.
Los datos a cargar tienen que tener la siguiente configuracin
define host{
use servidor-linux
host_name ortega
alias ortega - servidor Oracle Dialnet
address ***.***.***.***
parents fw-shrek-svr
contact_groups syc,dialnet,dba-dialnet
}
7.4 Implementacin de los servicios en Sistemas
7.4.1 Identificacin de servicios
Los servicios que hay que implementar para Sistemas sern los mismos que tenemos en
la configuracin previa de Nagios ms alguno nuevo que se tendr que aadir.
Pgina 62 de 135
Tambin se tendr que poner alguno de los mismos servicios que hay en
comunicaciones como carga de CPU.
Los servicios son los siguientes
Acceso a Web por http y https

Caducidad de certificados
Chequeo de cuentas de correo
Servicio NTP
Conexiones TCP
Estado de BD de Oracle
Disponibilidad de las particiones de disco
Estado de Host virtuales
7.4.2 Valores crticos
Servicio Warning Critical

UR_HTTP Tiempo de respuesta No se establece
UR_HTTPS Tiempo de respuesta No se establece
UR_CERT 1 da para expirar el Certificado expirado
certificado
UR_ORACLE_LOGUIN ------- No se establece
conexin
UR_CONNECTION_FIREWALL 94% de conexiones 97% de conexiones
UR_TUNEL_DIALNET ------- No hay conexin
UR_PROCESS ------- Proceso no existe
UR_POP3S 10 correos 50 correos
UR_TCP ------- Sin conexin tras 10
segundos
UR_SMTP Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_SMTP_SEND Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_SSMTP_SEND Tiempo de respuesta No responde
alto (tiempo por
defecto)
UR_DNS ------ El DNS no responde
UR_IMAP ------ No responde
UR_FTP ------- No hay conexin
UR_VIRTUAL_HOST Tiempo de respuesta El servidor no escucha
alto en el puerto
Pgina 63 de 135
7.5 Implementacin de plugins de Sistemas
Los plugins implementados para sistemas utilizan el mismo esquema general que los
implementados en comunicaciones. Todos los datos devueltos por los comandos han de
estar debidamente formateados para ser comprendidos por Centreon.
7.5.1 Comando ur_ceck_cert
Con este script se quiere comprobar la fecha de caducidad de los certificados que se
tienen, para ello se realiza una consulta que nos devuelve la fecha de caducidad del
certificado y la comparamos con la fecha actual, comprobando cunto tiempo falta y
lanzando un aviso dependiendo de ese tiempo.
ur_check_cert.sh HOSTADDRESS $ARG1$
$ARG1$: Puerto
Ejemplo:
./ur_check_cert.sh HOSTADDRESS 443
OK - Certificate expires in 309 day(s) on 01/10/2014 23:59.
7.5.2 Comando ur_check_connections
Con este comando queremos ver el porcentaje de conexiones que estamos utilizando en
el servidor, para ello realizaremos una consulta SNMP para saber el nmero de
conexiones que tenemos, el OID que utilizaremos ser el 1.3.6.1.4.1.2620.1.1.25.3 que
responde al nombre de fwNumConn, este OID se encuentra en la CHECKPOINT-
MIB, he introduciremos el nmero mximo de conexiones que queremos que el servidor
tenga antes de enviarnos una alerta. Se realizar una comparacin y se devolver un
valor porcentual que nos indica el porcentaje de conexiones realizadas respecto al
mximo introducido.
ur_check_connections.sh HOSTADDRESS $ARG1$ $ARG2$ $ARG3$ $ARG4$
$ARG1$: Community
$ARG2$: Lmite mximo de conexiones
$ARG3$: Valor warning en porcentaje
Pgina 64 de 135
$ARG4$: Valor de crtico en porcentaje
Ejemplo:
./ur_check_connections.sh HOSTADDRESS Community 60000 95 98
CONNECTIONS USED: 59.36% | CONNECTIONS_MAX=60000

CONNECTIONS_USED=35619
7.5.3 Comando ur_check_tunnel_dialnet
Con este comando queremos chequear el estado del tnel permanente con la fundacin
Dialnet, para ello realizaremos una consulta SNMP al OID
1.3.6.1.4.1.2620.500.9003.1.3 que se encuentra en la CHECKPOINT-MIB, que nos
dar el estado del tnel. Los valores que nos puede devolver son los siguientes:
3, para tnel activo

131, para tnel cado
Cualquier otro nmero, desconocido
Una vez realizada la consulta devolveremos el estado del servicio dependiendo del valor
obtenido.
./ur_check_tunnel_dialnet.sh HOSTADDRESS $ARG1$
$ARG1$: Community
Ejemplo:
./ur_check_tunnel_dialnet.sh HOSTADDRESS Comunity
TUNNEL DIALNET STATUS: 3 UP | TUNNEL_DIALNET_STATUS=1
7.5.4 Comando ur_check_virtual_host
Con este comando se ha de chequear el estado de las pginas Web alojadas en un

servidor con Host virtuales.
Realizar script para servidor balanceado
Con este script realizaremos el chequeo de la web en el host virtual, para ello primero el
servidor balanceado ejecutar el comando netstat para comprobar que el servidor est
escuchando en el puerto que est la pgina web.
Pgina 65 de 135
if[$(netstatan|grep$HOSTVIRTUAL:$PUERTO|grepLISTEN|wcl)ne1];then
echo"HTTPCRITICALelservidornoescuchalaspeticiones"
exit$STATUS_CODE_CRITICAL
fi
A continuacin, si el servidor escucha las peticiones correctamente, ejecutaremos el

comando check_http para comprobar el estado de la pgina web.
if[$PUERTOeq80];then
exec /etc/snmp/commands/check_http I "$HOSTVIRTUAL" p "$PUERTO" u "$WEB" r
"$CADENA"
else
echo"HTTPOKelservidorescuchalaspeticiones"
exit$STATUS_CODE_OK
fi
Solo se comprobar el comando check_http para el puerto 80 y no el 443 (puerto

seguro), ya que en todos los casos en los que ambos puertos atienden peticiones hay una
redireccin hacia el puerto 443.
Realizar script para Centreon
El script alojado en Centreon realizar una consulta SNMP al servidor balanceado

preguntando por el OID correspondiente al host virtual que queramos chequear.
Una vez realizada la consulta, obtendremos el estado de la web y devolveremos a
Centreon el estado del servicio.
#Conseguimoselestadodelhostvirtual

if[$PUERTOne80];then
STATUS_VALUE=$(echo$VALOR_RETORNO|cutd""f5)
VALOR_RETORNO=$(echo$VALOR_RETORNO|cutd":"f4)
else
STATUS_VALUE=$(echo$VALOR_RETORNO|cutd""f5|cutd":"f1)
VALOR_RETORNO=$(echo$VALOR_RETORNO|cutd":"f5)
fi

#DiscriminamossegunelvalordelestadoparaelserviciodeCentreon

case$STATUS_VALUEin
"OK")
echo$VALOR_RETORNO
exit$STATUS_CODE_OK
;;
"CRITICAL")
echo$VALOR_RETORNO
Pgina 66 de 135
exit$STATUS_CODE_CRITICAL
;;
"WARNING")
echo$VALOR_RETORNO
exit$STATUS_CODE_WARNING
;;
*)
echo$VALOR_RETORNO
exit$STATUS_CODE_ERROR
;;
esac
Configuracin del archivo snmpd.conf en el servidor balanceado
Los OID que utilizaremos corresponden a la siguiente rama .1.3.6.1.4.1.2021.*, y sern

a partir del 120.
Los OID los clasificaremos en 2 partes, los realizados al puerto 80, y los realizados al
puerto 443. Primero pondremos los host virtuales al puerto 80 y despus al puerto 443.
En el archivo snmp.conf del servidor balanceado hay que aadir una lnea por cada una
de las comprobaciones que queremos realizar. La mayora de los host virtuales tendr
dos lneas, una para el puerto seguro 443, y otra para el no seguro 80.
La lnea tendr este formato:
exec OID nombre-del-OID /compilador /comando/a/ejecutar parmetros
Ejemplo:
exec .1.3.6.1.4.1.2021.120 check-vhost-universidad80 /bin/bash

/etc/snmp/commands/ur_check_virtualhost.sh xxx.xxx.xxx.xxx 80
http://www.unirioja.es/ universidad
En el ejemplo podemos ver que utilizamos el OID .1.3.6.1.4.1.2021.120, que el nombre

asignado es check-vhost-universidad80, que el compilador utilizado es /bin/bash, la ruta
donde se encuentra el script y los parmetros que utiliza el script.
Al realizar estos cambios en snmpd.conf se nos crea una rama en la MIB. Si realizamos
snmpwalk sobre ese OID nos da el siguiente resultado
snmpwalk -v 2c -c community ***.***.***.*** .1.3.6.1.4.1.2021.129

UCD-SNMP-MIB::ucdavis.129.1.1 = INTEGER: 1
UCD-SNMP-MIB::ucdavis.129.2.1 = STRING: "check-vhost-biblioteca443"
UCD-SNMP-MIB::ucdavis.129.3.1 = STRING: "/bin/bash
/etc/snmp/commands/ur_check_virtualhost.sh xxx.xxx.xxx.xxx 443
http://biblioteca.unirioja.es/ biblioteca"
Pgina 67 de 135
UCD-SNMP-MIB::ucdavis.129.101.1 = STRING: "el servidor escucha las peticiones"
UCD-SNMP-MIB::ucdavis.129.103.1 = ""
Podemos ver cmo ha puesto en la MIB todo lo introducido en el archivo snmpd.conf,

concretamente a nosotros nos interesa el OID UCD-SNMP-MIB::ucdavis.129.101.1
donde nos da el resultado del chequeo del Host virtual.
7.6 Servicios Windows
Como se explic anteriormente los servicios Windows se pueden realizar mediante

NRPE o SNMP. Nosotros decidimos hacerlos por SNM. Esta opcin se cree la ms
conveniente dado que se est pasando todos los servicios posibles a SNMP.
Para poder realizar consultas SNMP a Windows ha de activarse el servicio SNMP en

los servidores Windows. Dado que nosotros no tenemos acceso a los servidores de
Windows no podemos activar el servicio SNMP, por ello ser nuestro responsable del
Servicio Informtico quien se encargue activar el servicio SNMP.
De las posibles soluciones que tenemos para realizar los servicios nos decantamos por
utilizar los comandos que vienen por defecto en Centreon ya que para los recursos que
queremos monitorizar son suficientes.
7.6.1 check_centreon_snmp_cpu
Con este comando veremos el uso de la CPU en el servidor, el comando tiene la

siguiente estructura.
check_centreon_snmp_cpu -H $HOSTADDRESS$ -v 1 -C $ARG1$ -c $ARG2$ -w

$ARG3$
-H: Direccin IP del servidor

-v : versin de SNMP
-C: Community del SNMP
-c: Valor critico
-w: Valor de warning
7.6.2 check_centreon_snmp_remote_storage
Con este comando veremos el espacio en disco disponible. La estructura del comando
es la siguiente:
Pgina 68 de 135
check_centreon_snmp_remote_storage -H $HOSTADDRESS$ -n -d $ARG1$ -w

$ARG2$ -c $ARG3$ -C $ARG4$ -v 2

-n -d: El nombre de la particin
-c: Valor crtico
-v 2: versin de SNMP
7.6.3 check_centreon_snmp_memory
Con este comando veremos el uso de memoria en el servidor tanto al RAM como la
SWA. La estructura del comando es la siguiente:
check_centreon_snmp_memory -H $HOSTADDRESS$ -C $ARG1$ -v 2c -w $ARG2$

-c $ARG3$

-v : versin de SNMP
-c: Valor crtico
7.6.4 check_centreon_snmp_process
Con este comando podremos ver si un proceso en concreto est funcionando en el

servidor. La estructura del comando es la siguiente:
check_centreon_snmp_process -H $HOSTADDRESS$ -v $ARG1$ -C $ARG2$ -p

$ARG3$

-v: versin de SNMP
-p: Nombre del proceso
Pgina 69 de 135
8 Mejoras del Sistema de monitorizacin

8.1 Copia de Seguridad del sistema
En este esquema vemos como se realiza el backup de los servidores de Comunicaciones

y de Sistemas.
Archivo Forcambios.php
Resumen Web principal de la backup
Localizacin Servidor comunicaciones
Descripcin En esta web se introducirn los datos de autor y los cambios
realizados en el sistema y se le dar al botn aceptar para crear el
backup
Archivo Cogernota.php.php
Resumen Recogida de datos
Localizacin Servidor de comunicaciones
Pgina 70 de 135
Descripcin Con este archivo se recogern los datos de autor y cambios

introducidos y se mandara realizar las backup de comunicaciones y
sistemas
Archivo centreon-completo-backup.sh
Resumen Ejecucin de script para la realizacin de backups
Descripcin Se realizan los comandos para ejecutar los 2 script de backups
Archivo Comunicaciones-nagios-backups.sh
Resumen Creacin de backup de comunicaciones
Descripcin Se realiza un archivo comprimido con los archivos de
configuracin de Centreon, Nagios y NagVis y se guardan en el
servidor de comunicaciones
Archivo Sistemas-nagios-backup-remoto.sh
Resumen Ejecucin remota de backup
Descripcin Ejecutamos remotamente el script de backup de Nagios de sistemas
Archivo Sistemas-nagios-backup-.sh
Resumen Creacin de backup de sistemas
Localizacin Servidor de sistemas
Descripcin Se realiza un archivo comprimido con los archivos de
configuracin de, Nagios y se guardan en el servidor de sistemas
Una vez creadas las backup, se proporcionaran los directorios donde se guardan las
copias de seguridad al administrador de seguridad del Servicio Informtico para que los
introduzca dentro de la poltica de backup corporativa.
8.2 Mapas de red
Para realizar los mapas de red utilizaremos el programa NagVis.
Con los mapas adems de ver la distribucin de los equipos, podremos ver qu servicios
o Host estn cados. Esta informacin la obtendremos mediante el color asignado a los
host y servicios. Aparte si hacemos clic en el icono del host o servicio accederemos a
una vista de Nagios.
Para realizar los mapas de red utilizaremos unas plantillas llamadas backend, donde
configuraremos el programa para que sepa dnde est la informacin para buscar los
datos del mapa y qu queremos que nos dibuje en ellos, como los nombres de los
equipos, el estado de los servicios, cuntos hijos y padres del Host nos ha de mostrar
Pgina 71 de 135
8.2.1 Mapas de la monitorizacin de comunicaciones
Los mapas de red que necesitemos los crearemos con el programa Nagvis. El criterio
para realizar los mapas ser segn su geografa. Tendremos un mapa por cada edificio
del campus, con lo que nos quedan los siguientes mapas:
REC (rectorado)
CPD
DEP (departamental)
FUR (Fundacin)
FIL ( Filologas)
CCT-ATRIO
CCT-ITA
CCT-QMC
QUI ( Quintiliano)
BIB (Biblioteca)
AMP (Ampliacin)
PLD (Polideportivo)
VIV (Vives)
Crearemos un mapa general donde ver la conexin que tienen los distintos edificios
entre s, llamado Campus. Tambin tendremos una serie de submapas dentro de CPD.
Los mapas realizados son los siguientes:
Mapa del Campus

Mapa del Rectorado
Mapa del CPD
Mapa del edificio departamental
Mapa de la Fundacin
Mapa de Filologas
Mapa CCT-ATRIO
Mapa CCT-ITA
Mapa CCT-QMC
Mapa Quintiliano
Mapa Biblioteca
Mapa Ampliacin
Mapa Polideportivo
Mapa Vives
A continuacin mostramos 2 mapas, el ms general (el campus) y uno ms concreto

(rectorado) como ejemplo.
Mapa del Campus
Pgina 72 de 135
Pgina 73 de 135
Mapa del Rectorado
8.2.2 Mapas de la monitorizacin de sistemas
Los mapas realizados para sistemas ser solo un mapa general mostrando todos los host
que hay en sistemas. Los mapas creados de los Host virtuales, donde se ve la
monitorizacin de las pginas Web alojadas en los Host virtuales.
Mapa de Sistemas
Pgina 74 de 135
Mapa de Host virtuales
Observaciones
En las imgenes de los mapas se pueden ver varios colores, verdes, amarillos, rojos,
azules y gris, estos colores representan los estados de alguno de los servicios del Host
al que representa el cuadrado, verde para OK, rojo para ERROR, amarillo para
WARNING y azul y gris para UNKNOW.
Pgina 75 de 135
Durante la realizacin del proyecto los mapas se quedaron todos en estado UNKNOW.
Esto se debi a un cambio en el nombre del sistema, que lo cambiamos de default a
comunicaciones, esto produjo que el backend buscase la configuracin de default y no
encontrara los datos. Para solucionarlo tuvimos que realizar un nuevo backend dndole
los parmetros de comunicaciones.
Los mapas estn realizados con la funcin de automapa que tiene Nagvis. Esta utiliza
relaciones de padre e hijo, estas relaciones nos las da el responsable del Servicio
Informtico y las definimos en Centreon, solo tenemos que darle un punto de origen y l
nos dibuja los hijos y padre que le indiquemos. Hay que tener en cuenta que estos
mapas son fijos, si luego hay cambios, hay que realizar el mapa de nuevo o realizar el
cambio manualmente. Durante el proyecto se han ido realizando cambios manualmente
cuando se aada un nuevo host al sistema de monitorizacin.
Pgina 76 de 135
9 Pruebas realizadas en la monitorizacin

Durante el proyecto se han realizado algunas pruebas para asegurarnos del correcto
funcionamiento del sistema, estas pruebas se realizaron sobre el sistema de
monitorizacin y sobre los scripts o servicios implementados.
Las pruebas realizadas para los script, han sido pruebas de ensayo y error, por lo que se
hacan a cada momento para verificar que el script nos daba el resultado deseado.
Las pruebas para el sistema fueron realizadas mediante mquinas virtuales con el
programa VMware.
Antes de realizar la instalacin en el servidor, se realiz la instalacin en una mquina

virtual, as se pudieron comprobar que funcionaban todos los pasos de la instalacin.
Las pruebas que se realizaron fueron las siguientes
Instalacin central
Instalacin distribuida
Actualizar la plataforma FAN
Pruebas en los servicios
Realizacin de copias de seguridad
Demonios cados
Instalacin Central
Pgina 77 de 135
Durante la instalacin de FAN como una mquina central que incluye todo (Centreon,
Nagios, Base de datos)
Descripcin Instalacin de FAN central

Resultado esperado Instalacin correcta y funcional
Resultado obtenido Instalacin correcta y funcional
Observaciones Ningn tipo de problema
Instalacin distribuida
Se realiz una instalacin distribuida con las mquinas virtuales. Para ello necesitamos
dos mquinas virtuales, una donde se instal el FAN Central y otra donde se instal el
poller de Nagios
Descripcin Instalacin de FAN central

Resultado esperado Instalacin correcta y funcional
Resultado obtenido Instalacin correcta y funcional
Observaciones Dificultades para que FAN Central detectara el poller de
Nagios. Problemas al actualizar FAN
Actualizacin de FAN
Para poder realizar la instalacin distribuida se tiene que actualizar FAN, por ello se
prob a actualizar FAN en una mquina virtual
Descripcin Actualizacin de FAN

Resultado esperado Actualizado a la ltima versin, todo funciona
correctamente
Resultado obtenido Los repositorios de FAN no funcionan correctamente, hay
que modificar las direcciones del repositorio
Observaciones Una vez puestos los repositorio correctamente la
actualizacin se completa con xito
Pruebas en servicios
Durante la realizacin de los script estos se fueron probando en la lnea de comando,

comprobando su correcto funcionamiento. Cabe destacar las pruebas realizadas con los
servicios para los Host Virtuales.
Descripcin Consulta SNMP a los OID creados

Resultado esperado Dato obtenido correctamente mediante consulta SNMP
Resultado obtenido Dato obtenido correctamente
Observaciones En algn caso la consulta SNMP no responda, esto se deba
a un error de transcripcin al configurar el archivo
snmpd.conf en los servidores
Pruebas de servicios Windows
Pgina 78 de 135
Probaremos los distintos servicios que se tienen que realizar en Windows, viendo que
funcionan correctamente todos
Descripcin Comprobacin de servicios Windows
Resultado esperado Obtencin de dato de la consulta SNMP a servidor
Windows
Resultado obtenido Obtencin de dato de la consulta SNMP a servidor
Windows
Observaciones Si se quiere monitorizar un proceso de Windows
necesitamos el nombre exacto del proceso (Ej.:
explorer.exe)
Pruebas en copia de seguridad
Pruebas para comprobar el correcto funcionamiento en la realizacin de copias de

seguridad
Descripcin Realizacin de copias de seguridad

Resultado esperado Archivos comprimidos de la configuracin del sistema,
tanto del servidor de comunicaciones como el de sistemas
Resultado obtenido Copia de seguridad obtenida satisfactoriamente
Observaciones Para poder realizar las copias de seguridad en sistemas y
comunicaciones mediante web se han tenido que dar los
permisos necesarios a apache para que pudiese ejecutar los
comandos necesarios para realizarlas
Demonios cados
Se han realizado unas comprobaciones en donde se puede ver qu sucede si alguno de

las herramientas que estamos utilizando deja de funcionar en el sistema y como afecta al
resto del sistema.
Los procesos o demonios que tiramos son los siguientes:
Nagios
Apache
Centreon
NDO
MySQL
Descripcin El demonio de Nagios se para

Resultado No hay monitorizacin
Relaciones con Apache No le afecta, tenemos web pero no funciona
Relaciones con NDO Se queda sin datos que guardar
Relaciones con MySQL No le afecta podemos seguir usando el SGBD
Relacin con Centreon No detecta el poller, y no muestra la monitorizacin
Descripcin El demonio de Apache se para
Pgina 79 de 135
Resultado No hay interfaz web

Relaciones con Nagios No le afecta, sigue monitorizando
Relaciones con NDO No le afecta sigue guardando los datos de la monitorizacin
Relaciones con MySQL No le afecta podemos seguir usando el SGBD
Relacin con Centreon No podemos acceder la interfaz web de Centreon
Descripcin El demonio de NDO se para

Resultado Los datos de la monitorizacin no se guardan
Relaciones con Apache No le afecta sigue funcionando
Relaciones con MySQL Sigue funcionando pero no recibe datos
Relacin con Centreon Funciona correctamente
Descripcin El demonio de MySQL se para

Resultado Perdemos acceso a la base de datos
Relaciones con Apache No le afecta
Relaciones con NDO No puede almacenar los datos
Relacin con Centreon Vemos la monitorizacin, pero no podemos ver ni crear
grficos
Descripcin El demonio de Centreon se para

Resultado Perdemos el acceso a Centreon
Relaciones con Apache No le afecta
Relaciones con NDO No le afecta
Relacin con MySQL No le afecta
Pgina 80 de 135
10 Gestin real del proyecto

La diferencia entre el tiempo estimado y el real han sido de unas 240 horas.
Este desfase se ha producido en las tareas de Implementacin de Sistemas y

Comunicaciones. Esto se debe a la inexperiencia a la hora de realizar la
implementacin, ya que si se produca algn tipo de error nos podamos quedar
atascados y el proyecto no avanzaba.
El siguiente grfico muestra el tiempo utilizado en cada tarea, y podemos ver cmo la
implementacin de sistemas y Comunicaciones se ha llevado el 56% del tiempo.
Direccin y gestin
Elaboracin del DOP

5% 2% 2% 7%
7%
Diseo
5%
Analisis del sistema de

monitorizcin
Implementacin de Sistemas
16%
y Comunicaciones
Pruebas
56%
Manual de usuario
Memoria
Concretamente este tiempo extra se ha utilizado en las tareas de Instalacin,

Implementacin de servicios, plugins y Servicios Windows, adems del cambio de
diseo de la arquitectura del sistema, que nos hizo realizar una nueva instalacin de la
herramienta en otro servidor, con los problemas de conectividad que conllev realizarla.
Tambin hay que tener en cuenta la tarea de Mantenimiento, que durante el proyecto ha
estado presente, realizando cambios puntuales en host y servicios y que tambin
conlleva un tiempo que no se ha podido usar en otras tareas.
Pgina 81 de 135
200
180
160
140
120
100
80
Tiempo real
60 Tiempo estimado
40
20
0
Implementa Implementa Implementa
Implementa
Instalacion cin de cin de cin
cin host
servicios plugins windows
Tiempo real 105 50 195 112 140
Tiempo estimado 44 50 88 52 50
Como muestra el grafico ms detallado de las tareas en la implementacin del sistema,

vemos como las tareas de instalacin, implementacin de servicios, plugins y servicios
Windows, nos han llevado mucho ms tiempo del estimado, mientras que la de
implementacin de host ha sido el tiempo estimado, ya que ha sido una tarea sin
complicaciones.
Esta mala estimacin se debe principalmente a que el proyecto trata sobre

conocimientos que se desconocan y los cuales han tenido que ser aprendidos durante la
realizacin del proyecto. Adems hay que sumar la inexperiencia del alumno en la
solucin de los problemas que han podido surgir durante la implementacin del sistema
de monitorizacin.
El diagrama de Gantt que se muestra a continuacin se ve el tiempo real dedicado al

proyecto.
Pgina 82 de 135
Pgina 83 de 135
10.1 Conclusiones
Al empezar la beca de colaboracin con el servicio informtico, ya tena planteado otro

proyecto, parecido al resto de trabajos que realizan otros compaeros de la carrera, pero
fue el trabajar con algo nuevo, algo que desconoca, las redes y servidores, las
herramientas de monitorizacin, y el que mi tutora de proyecto me sugiriera el cambio
lo que me animo a realizar este proyecto, que se sale algo fuera de lo comn respecto a
los dems, y por ello creo que es atractivo para un estudiante.
Durante su realizacin he trabajado en un entorno real, el Servicio informtico de la UR,

teniendo todos los problemas que se pueda tener en un entorno nuevo de trabajo
aadiendo adems la falta de conocimiento e inexperiencia de los temas a tratar en el
proyecto. Al estar en el entorno de trabajo real se han ido haciendo reuniones peridicas
con el jefe de proyecto en las que se ha ido informando del avance del proyecto,
solucionando problemas y viendo posibles mejoras que se podan aplicar al proyecto.
En algunas de las reuniones he tenido que realizar exposiciones para explicar los
conocimientos adquiridos, o justificar las decisiones tomadas, como en la arquitectura
del sistema, obteniendo experiencia en la exposicin oral, algo, a mi parecer, muy
importante en nuestra profesin.
Realizando este proyecto he adquirido conocimientos en el rea de las redes y

comunicaciones, algo que era desconocido para m, puesto que durante la carrera no hay
ninguna asignatura que profundic en esta rea. He aprendido a utilizar las herramientas
de Nagios, Centreon y NagVis, adems de que he tenido que profundizar en mis
conocimientos de Linux, ya que ha sido la plataforma en la que se ha realizado el
proyecto. Tambin he tenido que mejorar mis conocimientos con BBDD de MySQL,
virtualizacin a la hora de realizar las pruebas y programacin en la realizacin de los
Script para los servicios.
Actualmente el sistema de monitorizacin est listo para ser utilizado, y coexiste con el
antiguo sistema de monitorizacin. Solo es necesario dar de alta a los supervisores y
realizar un mantenimiento rutinario de la lista de Host y servicios para poder empezar a
utilizarlo al 100%, tarea que el administrador de la monitorizacin quiere realizar
cuanto antes.
En conclusin, creo que este proyecto me ha aportado nuevos conocimientos, ha sido

instructivo para trabajar en un entorno real, y ha sido el primer proyecto grande en el
que he trabajado, pudiendo ver los problemas a los que nos enfrentamos a la hora de
planificar y desarrollar el proyecto, y experimentando los imprevistos que suceden en el
transcurso de su realizacin, los cuales en un entorno controlado como el aula no somos
conscientes de ellos, a todo esto hay que aadirle la satisfaccin que da el realizar un
proyecto real el cual va a ser utilizado y no solamente presentado como ejercicio
academico.
Pgina 84 de 135
10.2 Informe del supervisor de la monitorizacin
D. Ignacio Lasheras Herrero

Tcnico de sistemas, comunicaciones y seguridad del Servicio Informtico de la
Universidad de la Rioja.
De mis consideraciones:
Por medio de la presente me permito expresar mi alto grado de satisfaccin en el

software de monitorizacin FAN implantado por Eduardo Laborda en el Servicio
Informtico de La Universidad de La Rioja.
Se han cumplido las expectativas y se ha mejorado la calidad del servicio de la

monitorizacin. Se han superado los requisitos iniciales de la monitorizacin y se han
completado hasta llegar a formar un sistema de monitorizacin completo y eficiente.
Durante su tiempo en el Servicio Informtico ha realizado el mantenimiento de la

monitorizacin satisfactoriamente y actualmente el software est listo para usarse al
100%.
Estoy completamente satisfecho por el trabajo realizado por Eduardo Laborda.
Atentamente,
Ignacio Lasheras
Pgina 85 de 135
11 Bibliografa
Toda la informacin utilizada para realizar este proyecto ha sido obtenida mediante
Internet.
Paginas Web para la documentacin:
http://www.fullyautomatednagios.org/
http://www.centreon.com/
http://www.nagios.org/
http://pandorafms.com/
http://www.zabbix.com/
http://es.wikipedia.org/
http://nagiosplugins.org/
http://www.cisco.com/web/learning/netacad/index.html
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
Pgina 86 de 135
12 Anexos
12.1 NRPE y SNMP
12.1.1 NRPE
NRPE es un plugin de Nagios que permite al sistema una monitorizacin remota

mediante secuencias de comandos que estn alojadas en los sistemas a monitorizar. Con
ello podemos monitorizar los recursos de supervisin, como el uso del disco, la carga
del sistema o el nmero de usuarios actualmente conectados. Nagios lanza el agente
peridicamente en el sistema remoto usando el plugin de check_nrpe.
NRPE consiste en 2 piezas:
-El plugin check_nrpe, que se encuentra en el servidor que monitoriza

-El demonio NRPE, que esta arrancado en el servidor Linux / Unix remoto a
monitorizar
Cuando Nagios tiene que monitorizar un recurso de un servidor Linux / Unix remoto
suceden las siguientes operaciones:
-Nagios ejecutar el plugin check_nrpe y le dir a el servidor remoto que el servicio se

debe comprobar
-El plugin check_nrpe contacta con el demonio NRPE de la mquina remota.
(Opcionalmente mediante una conexin segura SSL)
-El demonio NRPE ejecuta el plugin de Nagios apropiado para comprobar el servicio
-Los resultados del chequeo del servicio pasan por el demonio NRPE de nuevo al plugin
check_nrpe, que a continuacin, devuelve los resultados de la verificacin al proceso de
Nagios.
Nota: El demonio NRPE requiere que los plugins de Nagios sean instalados en el
sistema remoto. Sin stos, el demonio no sera capaz de monitorizar nada.
Los chequeos pueden ser directos o indirectos:
Pgina 87 de 135
Chequeo directo:
El uso ms sencillo del plugin NRPE es monitorizar recursos privados o locales en

un servidor remoto. Esto incluye cosas como la carga de la CPU, uso de memoria, los
usuarios actuales, uso de disco, los estados del proceso estos recursos son accesibles
por el servidor remoto directamente.
Chequeo indirecto:
Chequeos indirectos se producen cuando con el plugin NRPE queremos monitorizar

recursos pblicos o que no son accesibles directamente por el servidor a monitorizar.
Por ejemplo si queremos monitorizar una pgina Web, la cual es accesible por el
servidor remoto a monitorizar pero no por el servidor donde esta Nagios. En este caso
se puede configurar el demonio NRPE para permitir que el servidor remoto cheque la
Web directamente, en este caso el demonio NRPE est actuando como un Proxy.
12.1.2 SNMP (Protocolo Simple de Administracin de Red)
El Protocolo Simple de Administracin de Red o SNMP (del ingls Simple Network

Management Protocol) es un protocolo de la capa de aplicacin que facilita el
intercambio de informacin de administracin entre dispositivos de red. Permite a los
administradores supervisar el funcionamiento de la red, buscar y resolver sus
problemas, y planear su crecimiento.
Pgina 88 de 135
Las versiones de SNMP ms utilizadas son SNMP versin 1 (SNMPv1) y SNMP

versin 2 (SNMPv2).
Componentes bsicos
Una red administrada a travs de SNMP consiste de tres componentes claves:
Dispositivos administrados
Agentes
Sistemas administradores de red (Network Management Systems, NMSs).
Un dispositivo administrado es un servidor que se conecta a la red que contiene un

agente SNMP y reside en una red administrada. Estos recogen y almacenan informacin
de administracin, la cual es puesta a disposicin de los NMSs usando SNMP. Los
dispositivos administrados, a veces llamados elementos de red, pueden ser routers,
servidores de acceso, switches, bridges, hubs, impresoras.
Un agente es un mdulo de software de administracin de red que reside en un

dispositivo administrado. Un agente posee un conocimiento local de informacin de
administracin (memoria libre, nmero de paquetes IP recibidos, rutas, etctera), la cual
es traducida a un formato compatible con SNMP y organizada en jerarquas.
Un sistema administrador de red (NMS) ejecuta aplicaciones que supervisan y

controlan a los dispositivos administrados. Los NMSs proporcionan el volumen de
recursos de procesamiento y memoria requeridos para la administracin de la red. Uno o
ms NMSs deben existir en cualquier red administrada.
Comandos bsicos
Los dispositivos administrados son supervisados y controlados usando cuatro comandos
SNMP bsicos: lectura, escritura, notificacin y operaciones transversales.
El comando de lectura es usado por un NMS para supervisar elementos de red. El

NMS examina diferentes variables que son mantenidas por los dispositivos
administrados.
El comando de escritura es usado por un NMS para controlar elementos de red. El

NMS cambia los valores de las variables almacenadas dentro de los dispositivos
administrados.
El comando de notificacin es usado por los dispositivos administrados para reportar

eventos en forma asncrona a un NMS. Cuando cierto tipo de evento ocurre, un
dispositivo administrado enva una notificacin al NMS.
Las operaciones transversales son usadas por el NMS para determinar qu variables
soporta un dispositivo administrado y para recoger secuencialmente informacin en
tablas de variables, como por ejemplo, una tabla de rutas.
Pgina 89 de 135
Base de informacin de administracin SNMP (MIB)

Una Base de Informacin de Administracin (Management Information Base, MIB) es
una coleccin de informacin que est organizada jerrquicamente. Las MIBs son
accedidas usando un protocolo de administracin de red, como por ejemplo, SNMP.
Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de
cualquier nmero de caractersticas especficas de un dispositivo administrado. Los
objetos administrados estn compuestos de una o ms instancias de objeto, que son
esencialmente variables.
Existen dos tipos de objetos administrados: Escalares y tabulares. Los objetos escalares
definen una simple instancia de objeto. Los objetos tabulares definen mltiples
instancias de objeto relacionadas que estn agrupadas conjuntamente en tablas MIB.
Un identificador de objeto (object ID) identifica nicamente a un objeto administrado en

la jerarqua MIB. La jerarqua MIB puede ser representada como un rbol con una raz
annima y los niveles, que son asignados por diferentes organizaciones.
El rbol MIB ilustra las variadas jerarquas asignadas por las diferentes organizaciones
Los identificadores de los objetos ubicados en la parte superior del rbol pertenecen a
diferentes organizaciones estndares, mientras los identificadores de los objetos
ubicados en la parte inferior del rbol son colocados por las organizaciones asociadas.
Pgina 90 de 135
Los vendedores pueden definir ramas privadas que incluyen los objetos administrados
para sus propios productos. Las MIBs que no han sido estandarizadas tpicamente estn
localizadas en la rama de los rboles.
El objeto administrado atInput podra ser identificado por el nombre de objeto

iso.identified-
organization.dod.internet.private.enterprise.cisco.temporary.AppleTalk.atInput o por el
descriptor de objeto equivalente 1.3.6.1.4.1.9.3.3.1.
El corazn del rbol MIB se encuentra compuesto de varios grupos de objetos, los
cuales en su conjunto son llamados mib-2. Los grupos son los siguientes:
System (1);
Interfaces (2);
AT (3);
IP (4);
ICMP (5);
TCP (6);
UDP (7);
EGP (8);
Transmission (10);
SNMP (11).
Comandos SNMP
Snmpget
La orden snmpget se puede utilizar para obtener datos de un Host remoto dado su
nombre de Host, la informacin y un OID. Como ejemplo veamos la siguiente orden:
# snmpget -c public -v 2c localhost system.sysUpTime.0

SNMPv2-MIB::sysUpTime.0 = Timeticks: (326510) 0:54:25.10
Snmptranslate
Esta orden es una herramienta muy poderosa que permite explorar el rbol MIB de
diversas formas desde la lnea de rdenes. Su forma ms bsica permite pasar de un
OID a la variable que representa (representacin textual):
#snmptranslate .1.3.6.1.2.1.1.3.0
SNMPv2-MIB::sysUpTime.0
Tambin permite pasar del nombre de la variable al OID que representa:
#snmptranslate -On SNMPv2-MIB::system.sysUpTime.0
.1.3.6.1.2.1.1.3.0
Snmpwalk
Esta orden realiza una serie completa de getnexts automticamente y se detiene cuando
devuelve resultados que no estn en el rango del OID especificado originalmente. Por
Pgina 91 de 135
ejemplo, si quisiramos obtener toda la informacin almacenada en el grupo system del

MIB de una mquina podramos hacerlo utilizando esta orden:
# snmpwalk -v 2c -c public localhost system
Snmptable
Esta orden muestra una tabla SNMP en un formato de filas y columnas
Pgina 92 de 135
12.2 Manual de usuario
Instalacin de la herramienta de monitorizacin
Preparacin del servidor
El equipo donde se instalara la herramienta FAN Nagios es el servidor de

monitorizacin (HP PROLIANT DL 380 G4), este servidor tena instalado
previamente una instancia de Nagios, guardaremos sus archivos de configuracin para
una posible reutilizacin mas adelante.
Caractersticas del equipo:
Memoria RAM 4GB (se amplio su capacidad de 2GB a 4GB , poniendo 2

tarjetas de memoria RAM de 2GB cada una)
Tiene 80GB de disco duros actuales.
Durante la instalacin de FAN Nagios se creara un raid 0+1.
El disco duro le daremos las siguientes particiones, esto se debe a una decisin del
responsable del CPD, con estas particiones le estamos dando una parte de memoria para
la boot, otra para tener memoria SWAP por si la RAM se sobra, y el resto para
almacenar datos, creando los directorias de /raiz y /var:
/boot 100MB ext3

/swap 4094MB swap
/volumen 1 (resto) 134716MB
/raiz ext3 20480
/var ext3 102400
Una vez que este en marcha la monitorizacin tendremos que fijarnos cuanto ocupa la
base de datos, y si el volumen de datos aumenta muy rpidamente por si es necesario
ampliar el disco duro.
Pgina 93 de 135
Instalacin software
La instalacin de FAN Nagios es cmoda e intuitiva, solo necesitamos meter el CD de

instalacin con la ISO que descargamos de la pgina Web de FAN Nagios y seguir los
pasos que nos indica el asistente de instalacin.
El sistema operativo que se instala con FAN Nagios es un CentOS.
Lo primero que nos indica es que queremos instalar dndonos las siguientes opciones:
Instalacin centralizada, todo en un mismo servidor

Instalacin distribuida:
o FAN central: Instalacin de Centreon con Nagios.
o FAN poller: Instalacin de las distintas instancias de Nagios
o FAN databases: Instalacin de la base de datos
Una vez seleccionado el tipo de instalacin le indicaremos las particiones y los datos de
red para que el equipo tenga conexin de red.
Durante al instalacin nos pedir que le demos una contrasea para el usuario
administrador del sistema (root).
Pgina 94 de 135
Instalacin de Postfix
Nagios realiza notificaciones cuando tenemos alguna alerta en un Host o servicio, para
realizar estas notificaciones es necesario que el servidor este configurado para poder
mandar e-mails a los usuarios responsables del recurso, por ello es necesario instalar y
configurar postfix en el equipo.
Antes de instalar Postfix eliminamos Sendmail para evitar problemas ya que ambos
utilizan el mismo puerto para enviar correos. Podramos simplemente detener el servicio
Sendmail pero finalmente optamos por eliminarlo completamente.
Comandos utilizados:
Detener servicio Sendmail

# service sendmail stop
Eliminar Sendmail
# yum erase sendmail
Dependencias eliminadas:
mdadm.i386 0:2.6.9-3.el5
redhat-lsb.i386 0:4.0-2.1.4.el5
Como Postfix se encontraba en alguno de los repositorios por defecto de CentOS, no

fue necesario descargar ningn paquete manualmente ya que todo lo hizo el propio
sistema operativo.
Comando: yum install [NOMBRE_PAQUETE]
Los comandos necesarios para instalar Postfix se detallan a continuacin:
Comando: yum install postfix
Configuracin de Postfix
La configuracin de Postfix es muy sencilla. nicamente es necesario editar tres

archivos de texto, introduciendo los datos de nuestro servidor de correo.
Los datos de nuestro servidor y de la cuenta de correo que utilizaremos para el envo
de las alertas son los siguientes:
Pgina 95 de 135
Datos del servidor:
Direccin: xxxx.unirioja.es
Puerto: 587
Datos de la cuenta:
Usuario: xxxxxx-ext
Contrasea: [CONTRASEA]
Cuenta: [email protected]
Como queremos que Postfix se inicie automticamente cada vez que se arranque la
mquina, ejecutamos el comando siguiente:
Comando: chkconfig postfix on
Ahora vamos a configurar Postfix. Para ello es necesario editar tres archivos. Para
editar utilizamos el editor grfico gedit o el editor de consola vi, dependiendo de dnde
nos encontremos.
Modo grfico: gedit [NOMBRE_ARCHIVO]
Modo consola: vi [NOMBRE_ARCHIVO]
Pgina 96 de 135
El primer archivo que vamos a editar es main.cf. Lo que haremos es borrar TODO
su contenido e insertar el que viene a continuacin:
Archivo: /etc/postfix/main.cf
Contenido:
relayhost = [xxxx.unirioja.es]:587
smtp_tls_loglevel = 1
smtp_tls_CAfile = /etc/postfix/certs/CAcert.pem
smtp_tls_cert_file = /etc/postfix/certs/mycert.pem
smtp_tls_key_file = /etc/postfix/certs/mykey.pem
smtp_use_tls = yes
smtpd_tls_CAfile = /etc/postfix/certs/CAcert.pem
smtpd_tls_cert_file = /etc/postfix/certs/mycert.pem
smtpd_tls_key_file = /etc/postfix/certs/mykey.pem
smtpd_tls_received_header = yes
smtpd_use_tls = yes
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_generic_maps = hash:/etc/postfix/generic
En segundo lugar editamos el archivo sasl_passwd. En este caso insertamos al

final del archivo lo que viene a continuacin:
Archivo: /etc/postfix/sasl_passwd
Contenido:
[xxxx.unirioja.es]:587 xxxxxx-ext:[CONTRASEA]
Pgina 97 de 135
Por ltimo editamos el archivo generic. Al igual que en el archivo anterior,

insertamos al final del mismo lo que viene a continuacin:
Archivo: /etc/postfix/generic
Contenido:
root [email protected]
nagios [email protected]
La primera lnea hacer que todos los correos enviados por consola (usuario root) se
enven por la direccin deseada mientras que la segunda hace lo mismo pero con las
alertas que enva Nagios (usuario Nagios).
Una vez editados los archivos vamos a darles los permisos correctos y a generar las
bases de datos correspondientes.
Dar permisos a los archivos

# chmod 600 /etc/postfix/sasl_passwd
# chmod 600 /etc/postfix/generic
Crear las bases de datos

# postmap /etc/postfix/sasl_passwd
# postmap /etc/postfix/generic
Tras crear las bases de datos nos falta un ltimo paso, crear los certificados
necesarios para el envi de correos. Slo es necesario ejecutar los siguientes comandos.
NOTA: En caso de existir ya los certificados (no ser la primera vez que se configura
Postfix), eliminarlos todos antes de generar los nuevos o dar error.
Pgina 98 de 135
Creamos la carpeta de certificados

# mkdir /etc/postfix/certs/
# cd /etc/postfix/certs/
Creamos los certificados

# openssl dsaparam 1024 -out dsa1024.pem
# openssl req -x509 -nodes -days 3650 -newkey \
dsa:dsa1024.pem -out mycert.pem -keyout mykey.pem
# ln -s mycert.pem CAcert.pem
# openssl req -x509 -new -days 3650 -key \
/etc/postfix/certs/mykey.pem -out \
/etc/postfix/certs/mycert.pem
# rm dsa1024.pem
Por ltimo slo queda reiniciar la mquina. Tras el reinicio, podemos comprobar si el
servicio se inicia al arrancar y tambin podemos comprobar si podemos enviar un mail
por consola.
Reiniciar la mquina
# reboot
Comprobar si Postfix inicia arrancado

# service Postfix status
Enviar correo de prueba

# mail -s [ASUNTO] [DIRECCION_DE_CORREO]
(. Para terminar de escribir.)
Instalar FAN Nagios como Poller

Utilizaremos el CD de Fan Nagios y usaremos la opcin de instalar poller, con esto se
instalara automticamente lo que necesitamos, como una instalacin normal.
Pgina 99 de 135
Una vez instalado, actualizamos, es muy importante actualizar en este punto, ya que no
todas las versiones de FAN admiten una configuracin distribuida, por ello se ha de
actualizar a la ltima versin y as evitar estos problemas. (Ver apartado Actualizacin
de FAN en el manual de usuario).
Configurar Centreon central para detectar el poller de Nagios
Ahora seguiremos los siguientes pasos para configurar Centreon y el poller para que se
comuniquen (estos pasos tambin se pueden ver en la documentacin oficial de FAN
Nagios http://www.fullyautomatednagios.org/wordpress/configure-distributed-
monitoring/ http://www.r71.nl/kb/technical/345-centreon-add-a-poller ):
Asegurarse de que ndo2db esta funcionando en el poller central.

Permitir la comunicacin va ssh, sin password, entre FAN central y el poller.
En la Web de Centreon, ir a Configuracin > Centreon > Poller y aadir uno
con los datos de nuestro nuevo Nagios.
En Configuracin > Centreon > ndomod aadir uno nuevo con los datos de
nuestro nuevo poller.
Configurar sudo para poder start, stop, restart nagios
nagios ALL=NOPASSWD: /etc/init.d/nagios restart

nagios ALL=NOPASSWD: /etc/init.d/nagios stop
nagios ALL=NOPASSWD: /etc/init.d/nagios start
Pgina 100 de 135

nagios ALL=NOPASSWD: /etc/init.d/nagios reload

nagios ALL=NOPASSWD: /usr/sbin/nagiostats
nagios ALL=NOPASSWD: /usr/sbin/nagios *
En el poller de Nagios descargar, compilar e instalar NDOMOD
cd /tmp
wget http://sourceforge.net/projects/nagios/files/ndoutils-1.x/ndoutils-
1.4b9/ndoutils-1.4b9.tar.gz/download
tar xvzf ndoutils-1.4b9.tar.gz
cd ndoutils-1.4b9
./configure --codefix=/usr/local/nagios/ --enable-mysql --disable-pgsql --with-
ndo2db-user=nagios --with-ndo2db-group=nagios
make
cp ./src/ndomod-3x.o /usr/local/nagios/bin/ndomod.o
chmod 774 /usr/local/nagios/bin/ndo*
chown nagios:nagios /usr/local/nagios/bin/ndo*
cp config/ndo* /usr/local/nagios/etc/
Asegurarnos de que los archivos de configuracin estn todos configurados

correctamente (nagios.cfg, ndomod.cfg, broker).
Activar la configuracin y comprobar en los log ( nagios.log, centcore.log) que
todo es correcto.
Si algo no funciona asegurarnos de que el ssh funciona, y que los archivos que
han de usar nagios y apache tienen los permisos adecuados.
Problemas durante la instalacin y configuracin del poller de Sistemas
Antes de realizar la instalacin en los servidores se hizo una instalacin de pruebas en

maquinas virtuales para comprobar que todo funcionaba correctamente, aun as, durante
la instalacin del poller de Sistemas se han encontrado diversos problemas, los
enumeramos a continuacin
Los 2 servidores ( central y poller) no se comunican

Centreon no detecta el poller
No se consigue logear sin password en el poller
Problemas al actualizar FAN, problemas con el Proxy y los archivos .repo.
Errores en ndomod, no se establece comunicacin entre el poller y Centreon.
Estos problemas retrasaron el avance del proyecto, ya que al no poder realizar la

instalacin no se poda avanzar en la implementacin de la monitorizacin.
Las soluciones a estos problemas fueron las siguientes:
Habilitar la comunicaciones entre las maquinas en los firewall de la universidad,

permitiendo que pudiesen comunicarse por los puertos que necesitbamos.
Actualizando Nagios a la versin 3.3.1, con la cual ya se puede realizar una
configuracin distribuida.
Pgina 101 de 135

Realizar las claves rsa y pasarlas manualmente a cada maquina para poder
realizar la conexin ssh sin password.
Para conseguir actualizar se aadieron los repositorios de FAN nuevos, ya que
los que vienen con la instalacin estaban obsoletos y no se poda actualizar la
herramienta.
Reinstalar la herramienta NDOUtils en el poller de sistemas manualmente, al no
poder actualizar mediante los repositorios, ya que al no estar en la ltima
versin, NDOUtils no era capaz de establecer comunicacin con Nagios.
Dar los permisos necesarios al usuario Nagios, no solo en el servidor central,
sino tambin en el del poller de sistemas.
Creacin de host, servicios, comandos, usuarios, plantillas y

host Group en Centreon
Host
Para aadir un Host en Centreon tendremos que ir a Configuration>Host>Add le

daremos al botn y nos saldr un formulario el cual tendremos que rellenar y le daremos
a el botn Save para guardar el nuevo Host.
A continuacin se detalla la informacin que se necesita rellenar para crear el Host
Informacin general
1. Host Template Name: nombre de la plantilla (solo una palabra, nombre nico)
2. Alias: alias de la plantilla (dato nico)
3. IP addres: direccin del Host (este dato lo dejaremos en blanco)
4. SNMP community: versin de SNMP que utiliza por defecto el Host.
5. Multiples plantillas: si queremos que un Host utilice varias plantillas, pondremos
aqu las que ha de utilizar
10. Check Period: cuando queremos que cheque el servicio

11. Check Command: comando que queremos ejecutar, el servicio a chequear
12. Args: argumentos del comando
Pgina 102 de 135

13. Max Check Attempts: intentos mximos lanzando el servicio antes de dar un error
si este no responde
14. Normal Check Interval: medida de tiempo que hay entre cada chequeo del servicio
15. Retry Check Interval: medida de tiempo que tarda en chequearse cuando se
reinicia el servicio
16. Active Checks Enable: activar/desactivar chequeos activos
17. Passive Checks Enable: activar/desactivar chequeos pasivos
Notificaciones
1. Notification Enable: permitir o no las notificaciones a los usuarios

2. Linked Contacts: contacto al que mandar las notificaciones
3. Linked Contact Groups: grupos de contactos a los que mandar las notificaciones
4. Notification Intervar: tiempo que se tarda en reenviar una notificacin si el Host
sigue cado o inalcanzable.
5. Notification Period: periodo de tiempo en el que se pueden mandar notificaciones
6. Notification Options: estados del Host en los que se mandaran notificaciones
7. First notification delay: tiempo de espera desde que el Host esta cado o
inalcanzable hasta que se manda la primera notificacin.
Relaciones
Linked Service Templates: plantilla para el servicio bsico para el Host.
Pgina 103 de 135

Otras opciones que podemos realizar con los Host son las de borrar, modificar,
modificacin masiva, habilitar, deshabilitar. Para hacer cualquiera de ellas
seleccionaremos los Host y le daremos a la opcin que queremos realizar
Servicios
Para aadir un servicio en Centreon tendremos que ir a Configuration>Services,

seleccionaremos el Host al cual le queremos aadir un servicio y le daremos al botn
Add, nos saldr un formulario el cual tendremos que rellenar y le daremos a el botn
Save para guardar el nuevo servicio
A continuacin se detalla la informacin que se necesita rellenar para crear el servicio
Informacin general
1. Service Template Name: nombre de la plantilla (solo una palabra, nombre

nico)
2. Alias: alias de la plantilla (dato nico)
3. Service template model: si queremos utilizar un modelo previo para la
plantilla del servicio
Pgina 104 de 135

Estado del servicio
18. Is volatile: si el servicio es voltil, es decir que cada vez que se cheque nos ponga
OK en su estado
19. Check Period: cuando queremos que cheque el servicio
20. Check Command: comando que queremos ejecutar, el servicio a chequear
21. Args: Argumentos del comando
22. Max Check Attempts: intentos mximos lanzando el servicio antes de dar un error
si este no responde
23. Normal Check Interval: medida de tiempo que hay entre cada chequeo del servicio
24. Retry Check Interval: medida de tiempo que tarda en chequearse cuando se
reinicia el servicio
25. Active Checks Enable: activar/desactivar chequeos activos
26. Passive Checks Enable: activar/desactivar chequeos pasivos
Notificaciones
8. Notification Enable: permitir o no las notificaciones a los usuarios

9. Implied Contacts: contacto al que mandar las notificaciones
10. Implied Contact Groups: grupos de contactos a los que mandar las notificaciones
11. Notification Intervar: tiempo que se tarda en reenviar una notificacin si el Host
sigue cado o inalcanzable.
12. Notification Period: periodo de tiempo en el que se pueden mandar notificaciones
13. Notification Options: estados del Host en los que se mandaran notificaciones
14. First notification delay: tiempo de espera desde que el Host esta cado o
inalcanzable hasta que se manda la primera notificacin.
Pgina 105 de 135

Relaciones
Linked to host template: plantilla para el servicio bsico para el Host.
Grupos de host
Para crear un host Group iremos a Configuration>Hosts>Hosts Group y le daremos al

botn de Add
A continuacin se detalla la informacin que se necesita rellenar para crear el Host

Group
Informacin general
Host Group Name: nombre del Host Group

Alias: alias del host group
SNMP Community & version: versin de SNMP y su community que utiliza por
defecto el Host Group
Relations
Linked Hosts: lista de host pertenecientes al Host Group
Pgina 106 de 135

Usuarios
Para crear un usuario nos iremos a Configuration>Users y le daremos al botn Add

Aadir usuario
Pgina 107 de 135

Los campos obligatorios son los siguientes
Full Name : nombre del usuario

Alias/Login: alias del usuario
Email: correo electrnico del usuario.
El resto de datos no es necesario rellenarlos.
Pgina 108 de 135

En esta pestaa rellenaremos los datos para un usuario de Centreon.
Reach Centreon Front-end: permitimos o no al usuario logearse en Centreon

Defaut Lenguage: idioma por defecto
Admin: el usuario es o no administrador
Authentication Source: donde queremos que se identifique el usuario en Centreon u en
un servidor LDAP
Permios usuario
Para darle permisos a un usuario en Centreon tenemos que ir a Administration >ACL, y

le daremos al botn Add, a continuacin de daremos los accesos a los recursos y a los
mens que queramos, y despus le aadiremos los usuarios que queremos que tengan
estos permisos.
Pgina 109 de 135

Comando
Para aadir un comando iremos a Configuration>Commands y le daremos al botn Add

para aadir un usuario (tambin se puede borrar, duplicar)
Command Name: nombre del comando

Command type: tipo de comando
Command Line: lnea de comando a ejecutar
Argument Example: argumentos de ejemplo para el comando
Argument Description: descripcin de los argumentos del comando
Pgina 110 de 135

12.3 Actas de reunion
12.3.1 Acta 1
Proyecto: Adecuacin, mejora y optimizacin de la plataforma de monitorizacin

Fecha: 04-10-2011
Lugar: Empresa - Lugar
Hora inicio: 11:00
Hora 12:00
finalizacin:
Asistentes: Asistente Empresa
Fernando Ros Servicio Informtico de
la UR
Ignacio Lasheras Servicio Informtico de
la UR
Eduardo Laborda
Orden del da: Presentacin de la beca e informacin del trabajo a realizar
Temas tratados:
1. Presentacin de la Beca
Se trataran los horarios, se indicara quienes son los responsables, y cul es el

lugar de trabajo
2. Monitorizacin de la red de la UR
Se realizara una explicacin de que trabajo se quiere realizar durante la

realizacin de la beca
Temas pendientes:
Tema Responsables Fecha resolucin

Realizar una presentacin de la Eduardo Laborda 10-10-2011
herramienta de monitorizacin
Pgina 111 de 135

12.3.2 Acta 2

Fecha: 10-10-2011
Hora inicio: 11:00
Hora 12:00
finalizacin:
la UR
la UR
Eduardo Laborda
Orden del da: Presentacin de la herramienta de monitorizacin (FAN Nagios)
Temas tratados:
1. Presentacin en FAN Nagios
Se presenta con un Power point el software de monitorizacin (FAN Nagios)
Temas pendientes:

Realizar instalacin de FAN Eduardo Laborda
Pgina 112 de 135

12.3.3 Acta 3

Fecha: 14-10-2011
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Orden del da: Fijar primeros pasos para la implementacin de la monitorizacin
Temas tratados:
1. Recoleccin de informacin
Se empiezan identificar algunos usuarios y Host, para realizar sus plantillas y

aadirlas a Centreon
2. Identificacin de servicios
Se comenta por encima algo de los servicios que tendremos que monitorizar
3. Backup
Se comenta la posibilidad de realizar algn tipo de backup mas adelante para

salvar la monitorizacin
Temas pendientes:

Aadir las plantillas, usuarios y Host Eduardo Laborda
comentados en la reunin a Centreon
Pgina 113 de 135

12.3.4 Acto 4

Fecha: 14-11-2011
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Orden del da: Comprobar avance del proyecto
Temas tratados:
1. Comprobacin del estado de FAN Nagios
Se comprueba el estado de los Host y servicios de FAN Nagios para aplicar

soluciones en los Host y servicios con errores.
2. Grficos en Centreon
Se encuentra un problema en la visualizacin de los grficos
3. Nuevos servicios y Hosts
Se ampla la lista de Hosts y servicios
4. Backup
Se comenta la realizacin de una mejora en la Web para realizar el backup de la

monitorizacin
Temas pendientes:

Aadir las plantillas, Host y servicios Eduardo Laborda
comentados en la reunin a Centreon
Aadir las descripciones a los Host Eduardo Laborda
Group
Definir los servicios para Switches y Eduardo Laborda
Pgina 114 de 135

servidores
Solucionar el problema en la Eduardo Laborda
visualizacin de los grficos en
Centreon
Pgina 115 de 135

12.3.5 Acta 5

Fecha: 29-11-2011
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Reasignacin de nombres de plantillas
Cambiar los nombres y las descripciones de las plantillas
3. SNMP en Windows
Se comenta que se tendr que activar el SNMP en Windows para dar de alta
servicios, se pide que se empiece a mirar como se ha de hacer
4. Reutilizacin de configuracin de Nagios
La configuracin antigua de Nagios se puede reutilizar, se ha de mirar que partes

se puede reaprovechar.
Observaciones:
Comentamos cmo funciona la carga de los archivos de configuracin de Centreon a

Nagios, con lo que se descarta una carga desde Nagios a Centreon, siempre es sentido
Centreon a Nagios, los cambios se hacen en Centreon y luego se aplican para que pasen
a Nagios. Si se realizan cambios directamente en la configuracin de Nagios, la prxima
vez que se cargue la configuracin de Centreon esos cambios se borrarn.
Temas pendientes:
Pgina 116 de 135


Explorar archivos de configuracin Eduardo Laborda
antigua y extraer los datos reutilizables
Asignar los nuevos nombres a las Eduardo Laborda
plantillas
Pgina 117 de 135

12.3.6 Acta 6

Fecha: 14-12-2011
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Mapas de red
Se habla de que mapas de red son necesarios realizar
Temas pendientes:

Continuar con la implementacin de los Eduardo Laborda
servicios en Centreon
Empezar a realizar los mapas de red con Eduardo Laborda
NagVis
Pgina 118 de 135

12.3.7 Acta 7

Fecha: 12-01-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Orden del da: Comprobar avance de la monitorizacin
Temas tratados:

2. Mapas de red
Se ensean los mapas realizados, se comentan cambios y nuevos mapas a realizar
3. Backup den la Web
Se comenta el aadir un nuevo link en la pgina Web que nos mande a otra
ventana donde realizaremos la backup del sistema de monitorizacin
4. Cambios en plantillas
Se comenta realizar algn cambio en las plantillas de Host y en los Host Group
Temas pendientes:

Cambiar los mapas de red con NagVis y Eduardo Laborda
realizar los nuevos
Pgina 119 de 135

Crear el backup mediante la Web Eduardo Laborda
Pgina 120 de 135

12.3.8 Acta 8

Fecha: 02-02-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Monitorizacin de sistemas
La parte de comunicaciones est casi terminada, se comenta como empezar con

la monitorizacin de sistemas
3. Arquitectura del sistema
Se habla de hacer una arquitectura central o distribuida cul es mejor para

nosotros?
Temas pendientes:

Ver las posibles arquitecturas para la Eduardo Laborda
monitorizacin de Sistemas
Pgina 121 de 135

12.3.9 Acta 9

Fecha: 24-02-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Arquitectura del sistema
Se comentan las ventajas de una arquitectura distribuida y se decide realizarla
Temas pendientes:

Realizar la instalacin del nuevo poller Eduardo Laborda
de sistemas en el nuevo servidor y
comunicarla con el servidor Central.
Pgina 122 de 135

12.3.10 Acta 10

Fecha: 22-03-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Orden del da: Comprobar avance de la monitorizacin e instalacin del poller
Temas tratados:

2. Instalacin del poller de sistemas
Se comentan los errores de conectividad entre el poller de sistemas y Centreon,

se intentan buscar posibles soluciones
Temas pendientes:

Probar las posibles soluciones Eduardo Laborda
comentadas en la reunin para que
funcione correctamente el poller de
Sistemas
Actualizar la plataforma de Eduardo Laborda
monitorizacin (FAN Nagios)
Pgina 123 de 135

12.3.11 Acta 11

Fecha: 04-04-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Configuracin de la monitorizacin de Sistemas
Se comprueba que es lo que se puede reutilizar de la configuracin de sistemas

antigua
3. Comandos NRPE a SNMP
Se dice que se han de utilizar SNMP para los nuevos comandos que se vayan a
implementar
Temas pendientes:

Hacer listado de Host y servicios de Eduardo Laborda
Sistemas y aadirlos a la configuracin
Cambiar o crear nuevos comandos con Eduardo Laborda
SNMP
Pgina 124 de 135

12.3.12 Acta 12

Fecha: 17-05-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Servicios de Sistemas
Se comprueban los servicios de sistemas y se quitan los que ya no son

necesarios. Se proponen soluciones para errores en algunos servicios de bases de
datos( hace falta instalar Oracle en el servidor)
3. Nuevos mapas de NagVis
Se identifican los nuevos mapas que hay que aadir en NagVis sobre la
monitorizacin de sistemas
Temas pendientes:

Aadir los nuevos mapas de NagVis Eduardo Laborda
Instalar El cliente de Oracle para poder Eduardo Laborda
realizar los servicios de loguin a bases
de datos
Pgina 125 de 135

12.3.13 Acta 13

Fecha: 31-05-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Servicios de Sistemas
Se comenta que servicios http y a que servidores son necesarios
3. Error en Centreon
Se comenta un error que hay en Centreon, hay una duplicidad en la pgina de inicio de
los servicios, solo es en la presentacin de los mismos, en la configuracin no hay
presente duplicidad. Investigarlo y comentarlo en la prxima reunin
4. Back Up de NagVis
Se quiere aadir los mapas de NagVis al backup que se realiza, as como la

configuracin de Sistemas
Temas pendientes:

Aadir los mapas de NagVis al back up Eduardo Laborda
Aadir Sistemas al back up Eduardo Laborda
Pgina 126 de 135

12.3.14 Acta 14

Fecha: 06-06-2012
Lugar: Despacho de Mara Vico
Hora inicio: 11:00

Hora finalizacin: 12:00
Mara Vico
Eduardo Laborda
Orden del da:

Explicacin del proyecto a realizar en la Beca de colaboracin
Documentos
relacionados:
Temas tratados:
1. Viabilidad del proyecto
Se explica el proyecto a realizar y se ve comenta si es viable como proyecto fin de

carrera
Pgina 127 de 135

12.3.15 Acta 15

Fecha: 15-06-2012
Lugar: Sala de reuniones del Rectorado
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Servicios de monitorizacin
Eliminar el servicio ping de los Host en los que no sea necesario
3. Error de Centreon
El error encontrado en la reunin anterior se produce por un cambio de nombre

en el poller de default a comunicaciones, esto se debe a que en la base de datos
no cambia el nombre antiguo sino que ha creado uno nuevo, y por ello se ven por
duplicado, uno por el poller default y otro por el poller de comunicaciones. Por
el momento no hay solucin ya que es un error de Centreon.
4. Servicios Windows
Se habla de empezar a realizar los servicios de Windows, Se ven las

posibilidades que han para Windows SNMP y NRPE, se quiere probar con
NSClient++, por lo que se instalara en un servidor con Windows y se probara
Temas pendientes:
Pgina 128 de 135


Activar el NSClient++ en un servidor Eduardo Laborda
Windows
Realizar servicios de CPU, RAM, disco, Eduardo Laborda
a un servidor Windows mediante
NSClient++
Pgina 129 de 135

12.3.16 Acta 16

Fecha: 20-07-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:
Se comprueba el estado de los host y servicios de FAN Nagios para aplicar

soluciones en los host y servicios con errores.
Se decide finalmente realizarlos servicios Windows mediante SNMP
Temas pendientes:

servicios Windows en Centreon
Activar el servicio SNMP en un servidor Eduardo Laborda
Windows
Realizar servicios de CPU,RAM, disco.. Eduardo Laborda
a un servidor Windows mediante SNMP
Pgina 130 de 135

12.3.17 Acta 17

Fecha: 07-09-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

Comprobacin de servicios Windows mediante SNMP
5. Cambios en los mapas de NagVis
Separar algunos mapas para verlos como mapas de servicios y mapas de host
Temas pendientes:

servicios Windows en Centreon
Realizar los cambios en los mapas de Eduardo Laborda
NagVis
Pgina 131 de 135

12.3.18 Acta 18

Fecha: 05-10-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Servicios Para host virtuales
Se habla de que son y que se quiere monitorizar de ellos
Temas pendientes:

Realizar monitorizacin de los host Eduardo Laborda
virtuales
Pgina 132 de 135

12.3.19 Acta 19

Fecha: 30-11-2012
Hora inicio: 11:00
Hora 13:00
finalizacin:
la UR
la UR
Eduardo Laborda
Temas tratados:

2. Servicios para host virtuales
Se comprueba que la monitorizacin de los host virtuales es correcta
3. Cambios en los Switches
Se cambian todos los Switches (WiFi) de la universidad, por lo que los servicio
que tenemos creados para monitorizar sus puertos ya no sirven, por lo que hay q
borrarlos y crear servicios nuevos con sus OID nuevos correspondientes al
fabricante de los Switches. Dado que esto se produce una vez que ya estaba
finalizado lo que se quera realizar para el proyecto, no se van a realizar estos
servicios, y ser el servicio informtico quien se encargue de ponerlos en FAN
Temas pendientes:

Realizacin de memoria Eduardo Laborda
Pgina 133 de 135

12.3.20 Acta 20

Fecha: 20-02-2013
Hora inicio: 11:00

Mara Vico
Eduardo Laborda
Orden del da:

Revisin de la Memoria
Documentos
relacionados:
Temas tratados:
1. Primera revisin de la memoria
Se corrigen y se comentan los cambios a realizar en la memoria
Temas pendientes:

Redaccin de la me memoria y de los Eduardo Laborda
cambios mencionados en la reunin
Pgina 134 de 135

12.3.21 Acta 21

Fecha: 11-04-2013
Hora inicio: 11:00

Mara Vico
Eduardo Laborda
Orden del da:

Revisin de la Memoria
Documentos
relacionados:
Temas tratados:
1. Segunda revisin de la memoria
Se corrigen y se comentan los cambios a realizar en la memoria para finalizarla
Temas pendientes:

Redaccin de la me memoria y de los Eduardo Laborda
cambios mencionados en la reunin
Pgina 135 de 135

Proyecto Fin de Carrera

Cargado por

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto Fin de Carrera

Cargado por

Copyright:

Formatos disponibles

PROYECTO FIN DE CARRERA

Adecuacin, mejora y optimizacin de la plataforma de

Fernando Ros Puente y Mara Vico Pascual Martnez-Losa

Facultad de Ciencias, Estudios Agroalimentarios e Informtica

Proyecto Fin de Carrera

Facultad de Ciencias, Estudios Agroalimentarios e Informtica

Ingeniera Tcnica en Informtica de Gestin

Adecuacin, mejora y optimizacin de la plataforma de monitorizacin de red y sistemas en

Fernando Ros y Mara Vico Pascual

6.3.5 Comando UR_check_disk_linux............................................................ 54

12.3.12 Acta 12.............................................................................................. 125

La Universidad de la Rioja tiene un sistema de monitorizacin de redes el cual quiere

La realizacin de este proyecto surge durante la estancia en el servicio informtico de la

3 Documento de Objetivos del proyecto

En este proyecto se quiere realizar la implantacin de un sistema de monitorizacin para

La parte de la red de la UR que se quiere monitorizar se divide en dos:

3.2 Antecedentes y Situacin actual

El servicio informtico de la Universidad de la Rioja lleva una monitorizacin de las

El servicio informtico de la UR tiene actualmente dos instancias de Nagios donde se

Facilitar la configuracin del sistema de monitorizacin. Nagios es una

Actualizar la interfaz del sistema de monitorizacin. Aunque Nagios nos

Mejorar los mapas de red. Nagios nos da la posibilidad de visualizar unos

Cambios en el protocolo de monitorizacin. En la monitorizacin, se estn

Generacin, almacenamiento y consulta en tiempo real de histricos.

Disponibilidad de un sistema de recuperacin ante desastres. Se podrn

Herramientas OpenSource. El software a utilizar para nuestro sistema de

Para realizar la ampliacin y mejora del sistema de monitorizacin se estudiarn varias

La monitorizacin que se ha de realizar abarcar la parte de Comunicaciones y

Se han de desarrollar los plugins necesarios para realizar la monitorizacin, o bien

La monitorizacin abarcar los siguientes host y recursos:

Por la monitorizacin de comunicaciones:

Disponibilidad del Host

Por la monitorizacin de sistemas:

Disponibilidad del Host

Se tendr que poder realizar una copia de seguridad de la herramienta de monitorizacin

Aspectos que no se realizarn durante el proyecto:

Realizacin de Event Handler, estos eventos se utilizan para solucionar un

3.4 Objetivos del proyecto

El objetivo del proyecto es la mejora y optimizacin de la plataforma de monitorizacin

Los aspectos a cubrir en el proyecto son los siguientes:

Estudio de distintas alternativas de software y eleccin del mismo.

Instalacin del software libre, configuracin y desarrollo de los mdulos

Identificacin de los equipos del CPD a monitorizar y definicin de su

Monitorizacin de los componentes reflejando los parmetros de supervisin y

Captura de los datos y procesado de la informacin para su posterior

Creacin de mapas de red que reflejen la distribucin de los dispositivos y los

Creacin de back-up de la plataforma para posible restauracin en caso de fallo

Cambio en el protocolo de los comandos de monitorizacin de NRPE a SNMP

Monitorizacin de tanto equipos Linux / Unix como Windows, teniendo que

Para la realizacin del proyecto se cree que la metodologa ms conveniente a utilizar es

En caso de que no se termine la tarea planteada en la reunin anterior se vern las

3.7 Estructura de descomposicin de tareas

Esta tarea se divide a su vez en tres subtareas distintas:

Entorno de trabajo: En esta tarea se nos mostrar dnde trabajaremos en el

o Tiempo estimado: 1 hora

Nuevas herramientas: Se usar tiempo en investigacin, anlisis, estudio,

o Tiempo estimado: 60 horas

Presentacin de las nuevas herramientas: Realizacin de una presentacin con al

Mantenimiento: En esta tarea se realizarn los cambios en los datos, as como