adecuación, mejora y optimización de la plataforma de ... · 3.10.2 pandora ... vmware esx y...

Eduardo Laborda Plá

Adecuación, mejora y optimización de la plataforma demonitorización de red y sistemas en la UR con

herramientas de software libre

Fernando Ríos Puente y María Vico Pascual Martínez-Losa

Facultad de Ciencias, Estudios Agroalimentarios e Informática

Proyecto Fin de Carrera

Matemáticas y Computación

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

PROYECTO FIN DE CARRERA

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Adecuación, mejora y optimización de la plataforma de monitorización de red y sistemas en la UR con herramientas de software libre, proyecto fin de carrera

de Eduardo Laborda Plá, dirigido por Fernando Ríos Puente y María Vico Pascual Martínez-Losa (publicado por la Universidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

Facultad

Facultad de Ciencias, Estudios Agroalimentarios e Informática Titulación

Ingeniería Técnica en Informática de Gestión Título

Adecuación, mejora y optimización de la plataforma de monitorización de red y sistemas en la UR con herramientas de software libre. Autor/es

Eduardo Laborda Plá Director/es

Fernando Ríos y María Vico Pascual Departamento

Matemáticas y computación Curso académico

2012-2013

PFC: Adecuación, mejora y optimización de la plataforma de monitorización de red y sistemas en la UR con herramientas de software libre.

1 Contexto ................................................................................................................... 5 2 Glosarios de términos ............................................................................................... 5 3 Documento de Objetivos del proyecto ..................................................................... 6

3.1 Generalidades ................................................................................................... 6 3.2 Antecedentes y Situación actual ....................................................................... 6 3.3 Alcance ............................................................................................................. 7 3.4 Objetivos del proyecto...................................................................................... 9 3.5 Metodología.................................................................................................... 10 3.6 Entregables ..................................................................................................... 11 3.7 Estructura de descomposición de tareas ......................................................... 12 3.8 Riesgos ........................................................................................................... 19 3.9 Software de monitorización............................................................................ 19 3.10 Estudio de alternativas en herramientas de monitorización ........................... 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 Análisis y selección de la herramienta de monitorización ..................... 23

4 Arquitectura de la plataforma de monitorización................................................... 24 5 Análisis del sistema de monitorización .................................................................. 27

5.1 Usuarios de la monitorización ........................................................................ 27 5.2 Host de la monitorización............................................................................... 28 5.3 Servicios de la monitorización ....................................................................... 30

5.3.1 Identificación de recurso a monitorizar .................................................. 32 5.3.2 Definición de los valores críticos (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 monitorización .......................................................................... 37 5.6 Elección de servidor de correo ....................................................................... 42 5.7 Comunicación y permisos con servidores ...................................................... 42 5.8 Copia de Seguridad del sistema...................................................................... 43

6 Implementación del sistema de monitorización en Comunicaciones..................... 45 6.1 Implementación 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 Implementación de servicios de Comunicaciones.......................................... 47 6.2.1 Identificación de recursos....................................................................... 47 6.2.2 Definición de los valores críticos (Warning, Critical) de los recursos... 48 6.2.3 Identificador de objeto (OID) ................................................................. 49 6.2.4 Identificación y descripción de plantillas de servicios ........................... 50

6.3 Implementación 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

Página 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 Implementación de la monitorización de Sistemas ................................................ 59 7.1 Arquitectura de la monitorización Sistemas................................................... 59 7.2 Instalación del poller de Sistemas .................................................................. 61 7.3 Implementación de Host en Sistemas............................................................. 61 7.4 Implementación de los servicios en Sistemas................................................. 62

7.4.1 Identificación de servicios ...................................................................... 62 7.4.2 Valores críticos ....................................................................................... 63

7.5 Implementación 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 monitorización ................................................................. 70 8.1 Copia de Seguridad del sistema...................................................................... 70 8.2 Mapas de red................................................................................................... 71

8.2.1 Mapas de la monitorización de comunicaciones .................................... 72 8.2.2 Mapas de la monitorización de sistemas ................................................ 74

9 Pruebas realizadas en la monitorización................................................................. 77 10 Gestión real del proyecto.................................................................................... 81

10.1 Conclusiones................................................................................................... 84 10.2 Informe del supervisor de la monitorización.................................................. 85

11 Bibliografía......................................................................................................... 86 12 Anexos ................................................................................................................ 87

12.1 NRPE y SNMP ............................................................................................... 87 12.1.1 NRPE...................................................................................................... 87 12.1.2 SNMP (Protocolo Simple de Administración 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

Página 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

Página 4 de 135


1 Contexto La monitorización es una parte muy importante dentro de las redes de comunicación, por ello, tener un sistema de monitorización eficiente es importante, ya que con él podemos identificar errores y problemas en las comunicaciones de forma rápida y así poder subsanarlos de forma eficaz. La Universidad de la Rioja tiene un sistema de monitorización de redes el cual quiere ser actualizado y mejorado. Este proyecto intentará mejorar el sistema actual de monitorización y ampliarlo. En esta mejora queremos aumentar los objetos a monitorizar y hacerlo de una manera eficiente. La realización de este proyecto surge durante la estancia en el servicio informático de la universidad, durante el periodo de una beca de colaboración. Al empezar este trabajo para la beca, se ve que puede ser viable como proyecto fin de carrera, y se propone su realización. El proyecto duró todo el año de la beca de colaboración, más 5 meses que se ha estado como prácticas en el servicio informático.

2 Glosarios de términos SNMP: Protocolo Simple de Administración de Red (Véase Anexos). NRPE: Ejecutor de plugins locales en equipos remotos (Véase Anexos). Host: Servidor o dispositivo de red. Servicio: Monitorización de un recurso de un servidor. Plugin: Comando para realizar servicios de monitorización. MIB: Base de Información de Administración. OID: Identificador de objeto. LDAP: Protocolo Ligero de Acceso a Directorios. Firewall: Parte de un sistema o una red que está diseñada para bloquear el acceso no autorizado. Switches: dispositivo digital lógico que tiene como función interconectar dos o más segmentos de red. SWAP: Memoria virtual. AP: Punto de acceso. NAS: Dispositivos de almacenamiento específicos a los que se accede desde los equipos a través de protocolos de red. DNS: Sistema de nombres de dominio. DHCP: Protocolo de configuración dinámica de host. NDOUTILS: Addon que permite almacenar la configuración, tests y resultados de Nagios. VMWare ESX y ESXi: Plataformas de virtualización. TCP: Protocolo de Control de Transmisión. Warning: Valor de peligro para los servicios, se produce un aviso al responsable del recurso que produce el aviso. Critical: Valor crítico para los servicios, se produce un aviso al responsable del recurso que produce el aviso.

Página 5 de 135


3 Documento de Objetivos del proyecto

3.1 Generalidades En este proyecto se quiere realizar la implantación de un sistema de monitorización 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 Situación actual El servicio informático de la Universidad de la Rioja lleva una monitorización de las redes de la universidad, actualmente la plataforma de monitorización 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 características principales figuran la monitorización de servicios de red, la monitorización 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 específicos para nuevos sistemas. El servicio informático 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 monitorización se quiere realizar por las siguientes razones:

Facilitar la configuración del sistema de monitorización. Nagios es una herramienta muy potente de monitorización, pero es muy difícil de configurar, sus archivos de configuración tienen una sintaxis única, y se ha de conocer bien para poder manejar la configuración de Nagios y realizar cambios. Cualquier error en la sintaxis de los archivos de configuración hace que Nagios deje de funcionar.

Actualizar la interfaz del sistema de monitorización. Aunque Nagios nos

viene con una interfaz Web para poder visualizar la monitorización, esta no tiene muchas posibilidades a la hora de ver algún tipo de gráfico o esquema de los datos de la monitorización, en los que poder ver o prevenir el comportamiento de los recursos monitorizados.

Página 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 visión acertada de la red monitorizada.

Cambios en el protocolo de monitorización. En la monitorización, se están

utilizando comandos NRPE para monitorizar los recursos de los host, este protocolo se quiere cambiar a SNMP.

Generación, almacenamiento y consulta en tiempo real de históricos. Tendremos que poder almacenar los resultados de la monitorización, estos datos podrán ser consultados en un futuro para ver tendencias en los recursos monitorizados.

Disponibilidad de un sistema de recuperación ante desastres. Se podrán realizar backups de los archivos de configuración y de las BBDD del sistema de monitorización, para que en caso de fallo en el sistema no perdamos nada de información.

Herramientas OpenSource. El software a utilizar para nuestro sistema de monitorización ha de ser un software libre.

Para realizar la ampliación y mejora del sistema de monitorización se estudiarán varias alternativas de software y se elegirá la más adecuada para nuestra monitorización.

3.3 Alcance La monitorización que se ha de realizar abarcará la parte de Comunicaciones y Sistemas, se han de implementar todos los servicios previos que hubiera en la monitorización antigua, además de los nuevos servicios que necesitemos. Se han de desarrollar los plugins necesarios para realizar la monitorización, o bien extraerlos de algún medio, ya sea de la configuración de monitorización previa, o mediante Internet. La monitorización abarcará los siguientes host y recursos: Por la monitorización de comunicaciones: Host:

Switches AP Cabinas de disco Firewall

Página 7 de 135


Recursos:

Disponibilidad del Host Memoria RAM Memoria SWAP Discos Duros Uso de CPU Estado de los puertos Ethernet

Por la monitorización 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 específicos (DNS, DHCP, Web, Balanceos…)

Se tendrá que poder realizar una copia de seguridad de la herramienta de monitorización a través de la Web, poniendo un link que nos envíe a una página donde poder crear la copia de seguridad de forma automática. Aspectos que no se realizarán durante el proyecto:

La monitorización solo incluye los equipos que hay en el CPD del servicio informático, los cuartos de comunicaciones del campus y los puntos acceso a la red de los edificios, no se incluye ningún equipo personal, ni los ordenadores de los despachos, ni los ordenadores de las aulas de los edificios del campus de la UR.

Página 8 de 135


Realización de Event Handler, estos eventos se utilizan para solucionar un

problema en un servicio automáticamente, por ejemplo al dar un problema un servicio http, que éste se reinicie automáticamente.

Desarrollar una nueva herramienta de monitorización. Desarrollar un protocolo de comunicación propio. Una monitorización 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 prácticas en el servicio informático, una vez finalice ese tiempo, se encargarán los empleados del servicio informático.

3.4 Objetivos del proyecto El objetivo del proyecto es la mejora y optimización de la plataforma de monitorización de red y sistemas de la UR, para ello se estudiarán diferentes opciones de software libre y se elegirá la más conveniente para el proyecto. Los aspectos a cubrir en el proyecto son los siguientes:

Estudio de distintas alternativas de software y elección del mismo. Instalación del software libre, configuración y desarrollo de los módulos

necesarios para capturar y mostrar los datos de funcionamiento de los equipos del CPD.

Identificación de los equipos del CPD a monitorizar y definición de su

criticidad.

Monitorización de los componentes reflejando los parámetros de supervisión 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 información para su posterior

visualización como gráficos en una interfaz Web, para poder ser analizados por los usuarios del sistema de monitorización, de forma que se puedan ver comportamientos en los recursos monitorizados y así realizar un mantenimiento preventivo y proactivo.

Creación de mapas de red que reflejen la distribución de los dispositivos y los

servicios monitorizados.

Creación de back-up de la plataforma para posible restauración en caso de fallo del sistema.

Página 9 de 135


Cambio en el protocolo de los comandos de monitorización de NRPE a SNMP

(siempre que sea posible).

Monitorización de tanto equipos Linux / Unix como Windows, teniendo que realizar servicios de monitorización específicos para cada sistema operativo.

3.5 Metodología Para la realización del proyecto se cree que la metodología más conveniente a utilizar es la del Círculo de Deming (PDCA), esta decisión se basa en que durante la realización del proyecto se realizarán reuniones periódicas con el codirector con el cual se decidirán las tareas a realizar y a comprobar los avances realizados en el proyecto.

Planificar En cada reunión 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 reunión se realizan los puntos tratados en ella implementando la monitorización. Verificar Una vez terminado de implementar los puntos tratados en la reunión 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 reunión anterior se verán las dificultades encontradas y se tratarán de solucionar para seguir avanzando.

Página 10 de 135


3.6 Entregables

Memoria Manual de usuario Gestión del proyecto Presentación

Página 11 de 135


3.7 Estructura de descomposición de tareas

Página 12 de 135


Dirección y gestión Esta tarea se divide a su vez en tres subtareas distintas:

Entorno de trabajo: En esta tarea se nos mostrará dónde trabajaremos en el sistema informático, en qué trabajaremos y cuál será el horario para la realización del proyecto.

o Tiempo estimado: 1 hora

Nuevas herramientas: Se usará tiempo en investigación, análisis, estudio,

selección y aprendizaje de nuevas herramientas para la realización del proyecto, así como tecnologías que no se han visto hasta el momento.

o Tiempo estimado: 60 horas

Presentación de las nuevas herramientas: Realización de una presentación con al

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

crear nuevos Host, añadir nuevos servicios o quitar alguno existente. Estos cambios se producen durante todo el proyecto ya que se hacen a petición del responsable del servicio informático in situ, dado que las redes y sistemas son entornos dinámicos, 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 realizarán 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 reunión se realizará un acta con todos los puntos hablados en la reunión y tareas propuestas hasta la siguiente revisión. Habitualmente se han realizado una media de 2 reuniones al mes, cuyas fechas se han programado según la complejidad de las tareas propuestas en cada una de ellas.


Elaboración del DOP

Conocimientos del SI: Se ha de aprender el funcionamiento del servicio informático, infraestructuras de sistema, comunicaciones, e integración de tecnologías.

o Tiempo estimado:40 horas

Identificación de requisitos: Se identificarán los objetivos que se van a realizar en el proyecto.

Página 13 de 135



Descomposición de tareas: Iremos descomponiendo el proyecto en subtareas hasta que podamos valorar el tiempo a invertir en solucionar el problema.


Diseño

Diagrama de arquitectura: Realizaremos un diagrama de la arquitectura del sistema.


Análisis del sistema de monitorización

Análisis de instalación del software: Analizaremos qué herramientas vamos a instalar en el servidor de monitorización.


Análisis de Host: en esta tarea analizaremos los Host, veremos cuáles han de ser añadidos y cómo.


Análisis de servicios: en esta tarea analizaremos los servicios de monitorización.


Análisis de plugins: En esta tarea analizaremos los plugins.

o Tiempo estimado: 36 horas Implementación de Sistemas y Comunicaciones

Instalación del software: instalaremos las herramientas que hemos decidido tener en el servidor de monitorización.


Implementación de Host: en esta tarea añadiremos los Host que tenemos al software.


Página 14 de 135


Implementación de servicios: en esta tarea añadiremos los servicios.


Implementación 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.

o Tiempo estimado: 50 horas 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.

o Tiempo estimado: 20 Manual de usuario

Redacción de manual de usuario: Realización de un manual de usuario exhaustivo.


Memoria

Recopilación de información: durante todo el proceso se irá recopilando información de los avances y cambios en el proyecto.


Redacción de la memoria: Se redactará la memoria con toda la información

recopilada hasta el momento y se le dará formato.

Página 15 de 135



Preparar defensa

Presentación: Realización de la presentación para la defensa del proyecto.


Según esta estimación nos saldrían un total de 752 horas aproximadamente, que corresponden al tiempo que se estará en la beca de colaboración.

Página 16 de 135


Página 17 de 135


de

el 2011 al 31 de julio del 2012, durante ese tiempo tendrá ue realizarse el proyecto.

M X J V D

El proyecto se realizará durante el horario de la beca de colaboración con la UR,lunes a viernes entra las 9:00 y la 13:00, dedicando 4 horas a la realización del proyecto, llegando hasta 5 si fuese necesario recuperar tiempo. La beca tiene una duración del 1 de octubre dq

L S 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 informático no tenemos acceso a los servidores y la información y por lo tanto no podemos avanzar en

eterminados puntos como la implementación del sistema.

or lo santa y

avidades, que son 3 semanas en las que está cerrada la universidad.

ión se muestra un gráfico con el porcentaje de tiempo que se invertirá en ada tarea.

d Hay que tener en cuenta también los días que son festivos en la Universidad y ptanto el Servicio informático está cerrado, y las vacaciones de semana n A continuacc

10%

10%

7%

22%

38%

7% 3% 3%

Dirección y gestión


Diseño

Analisis del sistema demonitorizciónImplementación de Sistemas yComunicacionesPruebas

Manual de usuario

Memoria

Página 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 planificación 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 habría que ajustar los tiempos de realización del mismo.

Cambio en las horas dedicadas al proyecto. Las horas dedicadas el proyecto se realizan dentro del servicio informático, por lo tanto los días que esté cerrado o en la finalización de las prácticas ya no se podría tener acceso al sistema y tendría que pedirse permisos especiales, esto puede tardar tiempo hasta que se concedan.

Incendios, Inundaciones,… (Daños 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 informático, esto puede demorar la implantación del proyecto.

3.9 Software de monitorización El software que tenemos que buscar tiene que cumplir los siguientes requisitos:

Ha de ser software libre, sin ningún coste. La herramienta ha de ser de fácil comprensión. Ha de dar soporte en toda la monitorización 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 monitorización. Se han de poder visualizar mapas de red.

Página 19 de 135


3.10 Estudio de alternativas en herramientas de monitorización En este apartado presentaremos diferentes alternativas para la herramienta de monitorización, para finalmente seleccionar la más conforme a nuestras necesidades. Herramientas de monitorización:

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 monitorización funciona bajo Linux, este es capaz de enviar alertas por email, SMS o mensaje instantáneo 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 más utilizada en cuanto a software de monitorización, con lo que tiene un soporte muy grande con foros, webs, y guías con los que ayudarnos en la implementación y en los posibles inconvenientes que tengamos durante su utilización.

Aunque la configuración es poco amigable, está basado en Web, donde podremos consultar el estado actual de nuestros equipos, históricos 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 monitorización, aunque tiene una versión libre, también cuenta con una versión de pago especial para empresas, está especialmente diseñado para grandes entornos.

Pandora FMS es capaz de enviar alertas mediante email, SMS o mensaje instantáneo cuando se produce una incidencia en alguno de los recursos monitorizados.

Página 20 de 135


Pandora utiliza un sistema de agentes para recoger la información de los recursos a monitorizar y los envían al servidor central. Pandora no solo es capaz de monitorizar elementos de red y sus recursos también, 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 características principales de Pandora FMS son:

Monitorización multiplataforma, Solaris, GNU/Linux, Windows… Adaptabilidad total, servicios, aplicaciones, puertos, procesos, ficheros log u

otra fuente de información. Monitorización remota. Gestión y lanzamiento de alertas adaptables. Generación de informes personalizada. Gestión Web. Arquitectura Cliente-Servidor. Alta capacidad de procesamiento.

3.10.3 Zabbix

Zabbix en una herramienta de monitorización de bajo coste, capaz de recoger datos de cualquier aplicación o servidor, con un sistema de envío y captura de datos a través de sus agentes. Es importante señalar que Zabbix es capaz de monitorizar, además, equipos Windows, AIX, FreeBSD, HP-UX, OpenBSD y Solaris “desde dentro” y personalizar sus agentes con parámetros 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 automáticamente los problemas, un sistema de monitorización, alertas y visualización de gráficos que no tienen otros sistemas de monitorización, ni siquiera los mejores programas comerciales.

Como principales características podemos destacar:

Administración completamente web. Escalabilidad. Probado hasta 10.000 dispositivos. Posibilidad de monitorizar redes internas y externas. Sistema de alertas (email, SMS) Creación de plantillas de configuración exportables/importables. Autodescubrimiento de dispositivos. Multiplataforma (Windows, Linux, AIX, Solaris…) Base de datos (Oracle, MySQL, PostgreSQL o SQLite).

Página 21 de 135


3.10.4 Centreon

Centreon es un software libre para el seguimiento y supervisión de la red basada en la información de la herramienta de monitorización Nagios.

Centreon ofrece una interfaz simplificada para hacer el sistema accesible a un mayor número de usuarios, incluidos los de carácter no técnico, en especial con los gráficos. Los técnicos, sin embargo, siempre tienen acceso a la información técnica en Nagios.

Con Centreon podemos configurar Nagios sin meternos dentro de los archivos de configuración, pudiendo configurar Nagios de una forma sencilla.

Características

Una interfaz multi-usuario intuitiva y personalizable Gestión de todos los archivos de configuración de Nagios (CGI, nagios.cfg

...) Una configuración de módulo de carga de Nagios Compatibilidad Nagios 1.x, 2.x Nagios, Nagios 3.x Prueba de la validez de la configuración con el depurador de Nagios Representaciones gráficas personalizadas de los recursos monitorizados Librería de plugins para comprobaciones básicas por SNMP Sistema de plantillas para host, servicios…

3.10.5 FAN (Full Automated Nagios) FAN es una plataforma de monitorización libre que engloba a varios software de monitorización (Centreon, Nagios, NagVis) El propósito de la herramienta FAN es proporcionar una instalación rápida y fácil, que incluye las herramientas más utilizadas en la comunidad Nagios. FAN está basado en CentOS, los programas que incluye son los siguientes:

Nagios: Aplicación central de monitoreo Nagios plugins: plugins para controlar diferentes equipos Centreon: Interfaz web para Nagios NagVis: asignación avanzada (geográfica, funcional, de servicios…) NDOUTILS: almacena los datos de Nagios en una base de datos MySQL

Características de FAN:

Una única ISO que contiene el sistema operativo y la aplicación Nagios Basado en CentOS Las herramientas están configuradas automáticamente.

Página 22 de 135


Fan es de libre distribución. Actualizaciones periódicas de FAN.

3.10.6 Análisis y selección de la herramienta de monitorización Aunque hay muchas más alternativas de software para la monitorización de una red, nos hemos centrado solo en estas 5 soluciones ya que son las más utilizadas, concretamente Nagios es la herramienta más utilizada y por lo tanto de la que más información y ayuda podemos obtener. En cuanto a las características técnicas 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, ahorrándonos trabajo y teniendo una clasificación de los Host y servicios por las plantillas, además de que utiliza a Nagios como núcleo para la monitorización. Dado que somos nuevos en la utilización de software de monitorización creemos que la elección más razonable es la que nos ayude a realizar el trabajo y nos dé el soporte necesario, por ello la elección más conveniente es FAN, ya que engloba a Centreon y Nagios, además 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 instalación nos las prepara para trabajar desde el primer instante, además de que con sus actualizaciones periódicas podremos tener siempre las últimas versiones del software. Con FAN también tenemos la ventaja de que no solo tendremos la ayuda y guías que podamos encontrar en la comunidad de Nagios, sino que también podremos utilizar las de Centreon y las de FAN las cuales son comunidades muy vivas. Además de todo lo anterior contamos con que FAN y las herramientas que lo forman son OpenSource.

Página 23 de 135


4 Arquitectura de la plataforma de monitorización El sistema a monitorizar consta de 2 partes, comunicaciones y sistemas. Planteamos las siguientes alternativas para la arquitectura del sistema:

Instalación Centralizada: Podemos tener distintos usuarios que tengan distintos permisos de acceso a servicios y Host. Podemos realizar una instalación centralizada, donde tendremos toda la monitorización y distintos usuarios que accederán a la parte correspondiente de la misma ya sea de comunicaciones o de sistemas.

Instalación distribuida: Podemos realizar la instalación de la monitorización de forma distribuida, es decir, tener varios sistemas de monitorización, 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 múltiples instancias de Nagios, esto hace que

tengamos varios servidores, uno por cada instancia o ‘poller’ de Nagios.

Monitorización centralizada Ventajas:

Bajo coste en hardware, solo tendremos un servidor. Sin problemas de comunicación entre las distintas instancias de monitorización,

ya que solo tendremos una. Proceso de backup fácil de realizar, al tener todos los archivos de configuración

juntos. Inconvenientes:

Si la maquina falla toda la monitorización se para. No se puede separar configuraciones, si en un futuro se quiere realizar una

arquitectura distribuida, esta se ha de empezar de cero.

Página 24 de 135


Monitorización distribuida Ventajas:

Tendremos dos configuraciones de Nagios separadas, fáciles de exportar, y en caso de fallo, solo se dejara de monitorizar una parte y no toda la monitorización.

Menos carga de trabajo para el servidor, ya que tendremos 2 servidores trabajando.

Inconvenientes:

Mayor coste en hardware, tenemos que tener dos servidores,

Página 25 de 135


La opción más beneficiosa para nosotros es la de una arquitectura distribuida por ello es la queremos realizar, pero para ello necesitamos tener 2 servidores mínimo, y dado que nuestros recursos actualmente solo nos permiten disponer de solo un servidor, tendremos que realizar una arquitectura centraliza. Si más adelante disponemos de un segundo servidor se realizarían los cambios necesarios para realizar una arquitectura distribuida.

Página 26 de 135


5 Análisis del sistema de monitorización

5.1 Usuarios de la monitorización El sistema de monitorización 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 monitorización. Los usuarios identificados son los siguientes:

Administrador Usuario supervisor de la monitorización

Centreon nos da la posibilidad de crear usuarios, dándoles permisos de acceso distintos a cada uno. El usuario administrador tendrá acceso a todo el sistema de monitorización, pudiendo cambiar la configuración del sistema. El resto de usuarios, serán supervisores de la monitorización, corresponden a personas físicas del servicio informático, estos usuarios tendrán acceso solo a lo que necesiten del sistema de monitorización. Durante la realización del proyecto solo se han dado de alta los usuarios, una vez que los usuarios empiecen a usar el sistema se les darán los permisos que necesiten, estos permisos tendrá que dárselos el administrador mediante las opciones ACL de Centreon.

Página 27 de 135


5.2 Host de la monitorización Los Host es el primer paso para implementar la monitorización, tenemos que obtener la lista de Host para añadirla 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 configuración de Centreon. Crearemos una plantilla general, donde tendremos todos los datos posibles definidos (Tiempo de chequeo, intentos máximos antes de enviar alertas, días que se mandan alertas…), y de ella heredarán todas las demás plantillas, así solo tendremos que ponerle el dato específico en cada una, el servicio básico que queremos ponerle, el nombre y la descripción 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

Página 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 Switch_3750 Switch Cisco Eth 3750 Switch_4500 Switch Cisco Eth 4500 Switch_9124 Switch Cisco Eth 9124 VC_Blade Virtual Connect Blade SVR_Linux SVR Linux SVR_Windows SVR Windows

Grupos de Host Los grupos en la monitorización se crean en función de dos clasificaciones distintas, una por tipo de servidor, y otra por localización del servidor, los servidores pueden pertenecer a uno o varios grupos de estas clasificaciones. La clasificación por tipo de servidor, no es una clasificación por “tipos” propiamente dicha, ya que no solo miramos qué servidor es, sino que también se clasifican según a qué red pertenece o qué sistema operativo contiene, dependiendo de lo que nos interese destacar. Según 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 : Máquinas 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 clasificación por localización tenemos que ver de forma rápida en donde se encuentran los equipos a monitorizar, esta clasificación concuerda con los distintos edificios del campus de la universidad, dándonos los siguientes grupos:

AMP: Ampliación de politécnico BIB: Biblioteca CCT-ATR: Cct-Atrio CCT-AUL: Cct_Aulario CCT-ITA: ITA

Página 29 de 135


CCT-QMC: Químicas DEP: Departamental FIL: Filologías FUR: fundación de la UR PLD: Polideportivo PLT: Politécnico QUI: Quintiliano RECT: Rectorado VIV: Vives

Además de los grupos anteriores, de la monitorización de Sistemas que tenían previamente nos da los siguientes grupos, los cuales serán 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 monitorización Cada uno de los Host que hemos identificado anteriormente tendrá un conjunto de servicios asociados con los que monitorizaremos sus recursos.

Página 30 de 135


Estos servicios tienen un comando asociado el cual es el encargado de recopilar la información requerida para la monitorización, para nosotros será el encargado de realizar las consultas SNMP al Host. Al igual que con los Host, también crearemos una serie de plantillas para los servicios para clasificarlos y diferenciarlos de forma rápida. Estas plantillas tendrán asociado un plugin o comando que será el encargado de recoger la información 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

Página 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 críticos (Warning, Critical) del recurso, en caso de tenerlos. El identificador de objeto (OID) del recurso.

5.3.1 Identificación de recurso a monitorizar Los recursos a monitorizar para la monitorización de Comunicaciones son los siguientes:

Ping: este servicio es el básico 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 básico de SNMP, este servicio lo tendrán 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 relación 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 partición 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 tráfico del puerto Ethernet.

Los recursos a monitorizar para la monitorización de Sistemas son los siguientes:

Acceso a Web por http y https. Caducidad de certificados. Chequeo de cuentas de correo. Servicio NTP. Conexiones TCP.

Página 32 de 135


Estado de BD de Oracle. Disponibilidad de las particiones de disco. Estado de Host virtuales.

Para todos estos recursos se crearán servicios con los cuales chequear el estado del recurso.

5.3.2 Definición de los valores críticos (Warning, Critical) del recurso

Cada servicio tiene unos valores de criticidad con los cuales al ser alcanzados o sobrepasados generarán unas notificaciones que serán mandadas vía correo electrónico al responsable del recurso. Estos valores los definimos en las reuniones junto con el responsable del Servicio informático 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 monitorización 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 monitorización de Comunicaciones tenemos los siguientes valores: SERVICIO WARNING CRITICAL Ping Pérdida del 0.79% Pérdida 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

alto (10 segundos) No se establece conexión

UR_HTTPS Tiempo de respuesta alto (10 segundos)

No se establece conexión

UR_CERT 1 día para expirar el certificado

Certificado expirado

UR_ORACLE_LOGUIN ------- No se establece conexión

UR_CONNECTION_FIREWALL 94% de conexiones 97% de conexiones UR_TUNEL_DIALNET ------- No hay conexión UR_PROCESS ------- Proceso no existe UR_POP3S 10 correos 50 correos

Página 33 de 135


UR_TCP ------- Sin conexión tras 10

segundos UR_SMTP Tiempo de respuesta

alto (tiempo por defecto)

No responde

UR_SMTP_SEND Tiempo de respuesta alto (tiempo por defecto)

No responde

UR_SSMTP_SEND Tiempo de respuesta alto (tiempo por defecto)

No responde

UR_DNS ------ El DNS no responde UR_IMAP ------ No responde UR_FTP ------- No hay conexión UR_VIRTUAL_HOST Tiempo de respuesta

alto El servidor no escucha en el puerto

5.3.3 El identificador de objeto (OID) de los recursos Para la monitorización 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 documentación del fabricante para saber en qué MIB buscar. Para buscar el OID tenemos dos opciones

Usar un MIB’s Browser (buscador de MIB). Realizar una búsqueda manual.

Si usamos un MIB’s Browser tendremos que cargar la MIB donde está el OID que queremos para realizar la búsqueda. Si realizamos la búsqueda 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 información del fabricante y de Internet para encontrar los OID que queremos.

Página 34 de 135


Los OID que utilizaremos se verán en el apartado de la implementación 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 monitorización 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:

Página 35 de 135


El comando en el servidor de monitorización. Un agente en el servidor a monitorizar para visualizar el recurso y devolver el

resultado al servidor de monitorización. La solución sería utilizar la herramienta NSClient++, con ella podríamos 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 monitorización 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 serán los siguientes:

Página 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 monitorización Los plugins son los comandos (scripts) que utilizan los servicios para obtener los datos de monitorización, por lo tanto tendremos que crear comandos para la monitorización del sistema. Estos plugins tenemos varias formas de obtenerlos:

Utilizar comandos de la antigua configuración. Utilizar comandos que vienen con Centreon por defecto. Buscar en Internet los plugins que nos puedan servir. Realizar nosotros los comandos.

Reutilización de comandos El servicio informático de la UR ya utilizaba previamente una monitorización de Comunicaciones y Sistemas, por lo tanto tendrá comandos que podremos reutilizar. Estos comandos serán aquellos que no usen el protocolo NRPE, estos comandos serán por ejemplo, los que chequean webs, bases de datos, acceso a ftp… Los comandos que reutilizaremos serán para la monitorización de Sistemas y serán 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 decisión se basa en que los

Página 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 fácilmente en Internet, concretamente en páginas especializadas en plugins para Nagios, donde los usuarios suben sus propias creaciones, o donde están 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 información de un Puerto Ethernet (tráfico, estado,…)

check_pop3_account: este comando se usaba previamente, se ha bajado la última versión y se ha reutilizado, nos da la información de una cuenta de correo (correo en la bandeja de entrada)

Comandos nuevos La mayoría de plugins los crearemos nosotros, para ello tendremos que saber qué es lo que queremos consultar vía 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

Página 38 de 135


En el siguiente diagrama de actividad, se muestra la actividad general que tendrán todos los scripts, comprobación de parámetros de entrada, consulta SNMP, procesamiento del dato y envío del resultado. Resumen Visión general de los script Actor principal Sistema de monitorización Precondición Realización de chequeo automático , o

forzado Postcondición Se realiza el chequeo del recurso Flujo básico -Se comprueba parámetros de entrada

-Se realiza la consulta SNMP -Se procesa el dato obtenido y se devuelve el resultado

Flujo alternativo Alguno de los parámetros introducidos es erróneo o se produce algún error en la consulta SNMP y se devuelve un mensaje de error.

Página 39 de 135


Sof tware de Monitorización Script (addon) de monitorización

Introducir parametros de entrada

Presentar resultado de monitorización

¿Consulta SNMP correcta?

Comprobar parametros de entrada

¿Parametros correctos?

Env iar error

Consulta SNMP

Env iar estado del recurso

Procesamiento del dato SNMP

NO

SI

Inicio

ad: Diagrama_general

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 gráficas. Esto se hará en el código de cada script antes de devolver el dato. El formato que se ha de enviar tiene que ser el siguiente:

Página 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 tubería y el formato para Centreon, una etiqueta para que el valor tenga nombre, seguido del valor del dato y su métrica (la métrica se puede omitir), el resto de valores como crítico, valor máximo o mínimo, se pueden omitir. Una vez en Centreon podemos ajustar los parámetros aquí omitidos para ver los gráficos que queremos. UR_check_virtual_host Con este comando se ha de chequear el estado de las páginas Web alojadas en un servidor con Host virtuales. Estas páginas web se encuentran por duplicado detrás de un servidor de balanceo, a la hora de monitorizar estas web, desde nuestro servidor de monitorización, solo somos capaces de ver el servidor de balanceo y comprobar ahí el estado de la página 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 solución para poder realizar una monitorización de los host virtuales.

La solución que implantaremos será crear un nuevo OID en el servidor de balanceo, el cual, haciendo una consulta SNMP desde nuestro servidor de monitorización, nos dará el estado de los host virtuales.

Página 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 añadirlo al servidor para así realizar la consulta SNMP. Utilizaremos una rama de la MIB en la que se puedan añadir 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 están siendo utilizados. Para la monitorización 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.

Configuración del archivo snmp.conf en el servidor balanceado.

5.6 Elección de servidor de correo Nuestro sistema de monitorización 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 código abierto. Sendmail nos sirve perfectamente para mandar las alertas por correo electrónico, 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, fácil de configurar y de los más seguros y además ya está siendo utilizado en el Servicio Informático para otros usos, con lo cual se conoce esta tecnología. Dado que nuestro servidor de monitorización va a tener conexión con todos los servidores del CPD, la seguridad es algo muy importante, y por ello, creemos que Postfix es la mejor elección como servidor de correo.

5.7 Comunicación y permisos con servidores Dado que el servidor de monitorización tiene que tener acceso a todos los servidores que se quieren monitorizar tendremos que darle permisos en los firewall que necesite

Página 42 de 135


para acceder a la red de comunicaciones. Estos permisos los tiene que dar el administrador de seguridad. También 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 configuración de la herramienta de monitorización tanto para Comunicaciones como para Sistemas. Para resolver este punto se barajaron varias opciones:

Añadir el servidor de monitorización al sistema de backup que se tiene en el Servicio Informático.

Realizar una mejora en la página web de la herramienta de monitorización para realizar la copia de seguridad.

Si realizábamos la primera opción todo el servidor sería copiado, y aunque es una solución es más de lo que necesitamos, ya que no solo se guardaría la configuración sino también todo el resto de datos que tiene el servidor y que no nos interesa guardar. Si se elige la segunda opción tendríamos que realizar la copia de seguridad en la web, y ésta se guardaría en el servidor de monitorización, teniéndola que sacar de ahí y guardándola en otro sitio, ya sea disco u otro servidor. Como solución se decidió realizar una mezcla de ambas opciones, se realizará la copia de seguridad de los archivos de configuración de Nagios, Centreon y NagVis mediante la página web, y se guardarán en un archivo comprimido en un directorio del servidor de monitorización, y el servicio de backup del Servicio Informático será el encargado de integrar esos datos dentro de la política de backup corporativa. Las BBDD donde se guardan los datos de la monitorización 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 deduplicación. Por lo tanto nosotros solo tenemos que realizar la copia de seguridad mediante la página Web y guardarla en un directorio del servidor de monitorización, del resto se encargara la herramienta de backup del servicio informático. Los archivos de configuración que tenemos que guardar son los de Nagios, ya que ahí está toda la configuración de host, servicios, plantillas… los mapas de Nagvis y la configuración de Centreon, donde tenemos los usuarios y la configuración de los ‘poller’.

Página 43 de 135


Para ellos realizaremos una modificación en la Web de Fan Nagios, poniendo un enlace que nos llevará a una nueva página donde podremos hacer la copia de seguridad.

Página 44 de 135


6 Implementación del sistema de monitorización en Comunicaciones

6.1 Implementación 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 algún 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 información que ya teníamos de la configuración previa de Nagios en el archivo host.cfg, aunque esto es una pequeña parte, el resto lo tendremos que sacar con las listas que nos dé el responsable del sistema informático consistente en una relación de IPs de varias redes de clase C. Con esta lista de quipos hemos de sacar sus nombres para poder identificarlos y añadirlos a la monitorización. 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 pequeño 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 estén en la lista como los que no estén. Además 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 búsqueda de MIB, búsquedas en Google o en documentación 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 también 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

Página 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

Página 46 de 135


Relaciones Linked Service Templates: Valor en blanco Los valores que se dejan en blanco, o no hacen falta o son específicos de cada Host y se rellanarán a medida que metamos los Host en la herramienta de monitorización.

6.1.3 Observaciones Durante este apartado se han ido añadiendo equipos hasta llegar a los 166 equipos monitorizados. Cuando se han ido buscando los nombres y modelos de los equipos mediante las consultas SNMP, teníamos que asegurarnos de que cuando esta no respondía era porque efectivamente no había ningún equipo en esa dirección y no por que no tuviese el servicio SNMP activado, para asegurarnos realizábamos la siguiente acción:

Se comprobaba la disponibilidad del equipo mediante el comando ping a las direcciones que estaban en la lista y no respondían al SNMP, así nos asegurábamos de que había un equipo en la dirección IP y que había que activar el servicio SNMP.

6.2 Implementación de servicios de Comunicaciones

6.2.1 Identificación 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:

Página 47 de 135


Ping: este servicio es el básico 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 básico de SNMP, este servicio lo tendrán 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 relación 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 partición 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 tráfico del puerto ethernet

6.2.2 Definición de los valores críticos (Warning, Critical) de los recursos

Cada servicio tiene unos valores de criticidad que al ser alcanzados o sobrepasados debemos generar unas notificaciones que serán mandadas vía correo electrónico al responsable del recurso. SERVICIO WARNING CRITICAL Ping Pérdida del 0.79% Pérdida 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.

Página 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 crítico.

6.2.3 Identificador de objeto (OID) Para la obtención de los OID que necesitamos para monitorizar los recursos que queremos será necesario mirar la documentación del fabricante de los dispositivos a monitorear. El fabricante es CISCO, por lo tanto es en su documentación donde tenemos que buscar los OID que nos interesan. En su página 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 información del recurso mediante SNMP. En caso de que no tengamos el nombre exacto del recurso para obtenerlo en la documentación del fabricante, tendremos las dos posibilidades citadas anteriormente:

Usar un MIB’s Browser (buscador de MIB) Realizar una búsqueda manual

La solución a utilizar será realizar una búsqueda manual. Esta decisión se basa en que la mayoría de MIB’s 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 búsqueda es tediosa ya que hay que ir viendo todo el árbol hasta dar con el dato que deseamos.

Página 49 de 135


6.2.4 Identificación y descripción 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 común de los servicios. La plantilla de SERVICE_GENERAL quedará de la siguiente forma Información general

Página 50 de 135


1. Service Template Name: SERVICE_GENERAL 2. Alias: SERVICE GENERAL 3. Service template model: Valor en blanco

Propiedades de chequeo del Host 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

Página 51 de 135


Relaciones Linked to host Templates: Valor en blanco

6.3 Implementación 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 quedaría 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

Página 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 información 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. El comando quedaría de la siguiente forma: ur_check_cpu_netapp.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG1$: Community $ARG2$: Tiempo ocupado u ocioso (busy / idle) $ARG3$: Valor warning $ARG4$: Valor critico 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 añaden 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 partición que se quiere chequear y si es el espacio usado o el libre.

Página 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

# snmpwalk ‐v 2c ‐c admmon 10.254.0.202 1.3.6.1.4.1.2620.1..1 SNMPv2‐SMI::enterprises.2620.1.6.7.6.1.1.1.0 = Counter32: 1 SNMPv2‐SMI::enterprises.2620.1.6.7.6.1.1.2.0 = Counter32: 2 SNMPv2‐SMI::enterprises.2620.1.6.7.6.1.1.3.0 = Counter32: 3 SNMPv2‐SMI::enterprises.2620.1.6.7.6.1.1.4.0 = Counter32: 4 SNMPv2‐SMI::enterprises.2620.1.6.7.6.1.1.5.0 = Counter32: 5 ….

Con este resultado podemos comprobar las particiones de disco, el número 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 también los usaremos en unos script auxiliares que usaremos para sacar los nombres de las particiones de forma automática, ya que no tenemos otra forma de saberlas y son necesarias para nombrar a los servicios. El comando quedaría de la siguiente forma: ur_check_disk_firewall.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG1$: Community $ARG2$: Partición de disco $ARG3$: Espacio usado o libre (used / free) $ARG4$: Valor warning $ARG5$: Valor critico 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.

snmpwalk ‐v 2c ‐c soloread 10.0.1.11 1.3.6.1.4.1.2021.9.1 UCD‐SNMP‐MIB::dskIndex.1 = INTEGER: 1 UCD‐SNMP‐MIB::dskIndex.2 = INTEGER: 2 UCD‐SNMP‐MIB::dskIndex.10 = INTEGER: 10 UCD‐SNMP‐MIB::dskIndex.11 = INTEGER: 11 UCD‐SNMP‐MIB::dskPath.1 = STRING: / UCD‐SNMP‐MIB::dskPath.2 = STRING: /proc

Página 54 de 135


UCD‐SNMP‐MIB::dskDevice.1 = STRING: /dev/mapper/LVM01‐LogVol00 UCD‐SNMP‐MIB::dskDevice.2 = STRING: proc UCD‐SNMP‐MIB::dskMinimum.1 = INTEGER: ‐1 UCD‐SNMP‐MIB::dskMinimum.2 = INTEGER: ‐1 ….

Todos estos datos están relacionados con el espacio en disco, en esta caso tenemos 11 particiones (ya que el índice va hasta el número 11), pero solo nos interesa una, para ello tenemos que identificar el número que tiene asignado y recoger los datos relacionados con él. El comando quedaría de la siguiente forma: ur_check_disk_linux.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG1$: Community $ARG2$: Partición de disco $ARG3$: Espacio usado o libre (used / free) $ARG4$: Valor warning $ARG5$: Valor critico 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 serán los siguientes, el de descripción de la partición, 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. El comando quedaría de la siguiente forma: ur_check_disk_netapp.sh $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG5$ $ARG1$: Community $ARG2$: Partición de disco $ARG3$: Espacio usado o libre (used / free) $ARG4$: Valor warning $ARG5$: Valor critico

Página 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

snmpwalk ‐v 2c ‐c soloread 10.3.1.51 1.3.6.1.4.1.2021.4 UCD‐SNMP‐MIB::memIndex.0 = INTEGER: 0 UCD‐SNMP‐MIB::memErrorName.0 = STRING: swap UCD‐SNMP‐MIB::memTotalSwap.0 = INTEGER: 1052248 UCD‐SNMP‐MIB::memAvailSwap.0 = INTEGER: 1052164 UCD‐SNMP‐MIB::memTotalReal.0 = INTEGER: 2075560 UCD‐SNMP‐MIB::memAvailReal.0 = INTEGER: 268844 UCD‐SNMP‐MIB::memTotalFree.0 = INTEGER: 1321008 UCD‐SNMP‐MIB::memMinimumSwap.0 = INTEGER: 16000 …

Lo que haremos será discriminar dependiendo si queremos RAM o SWAP y si queremos la memoria usada o la libre. El comando quedaría de la siguiente forma: 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) $ARG4$: Valor warning $ARG5$: Valor critico Ejemplo: ur_check_memory.sh HOSTADDRESS community ram used 75 90 RAM USED: 98.07% [TOTAL FREE 154MB]| RAM_USED=8089580 RAM_TOTAL=8248120

Página 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 descripción 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

snmpwalk ‐v 2c ‐c admmon 10.254.0.24 1.3.6.1.2.1.2.2.1.2 IF‐MIB::ifDescr.1 = STRING: Vlan1 IF‐MIB::ifDescr.99 = STRING: Vlan99 IF‐MIB::ifDescr.5001 = STRING: Port‐channel1 IF‐MIB::ifDescr.5002 = STRING: Port‐channel2 IF‐MIB::ifDescr.5004 = STRING: Port‐channel4 IF‐MIB::ifDescr.10101 = STRING: GigabitEthernet1/0/1 IF‐MIB::ifDescr.10102 = STRING: GigabitEthernet1/0/2 IF‐MIB::ifDescr.10103 = STRING: GigabitEthernet1/0/3 IF‐MIB::ifDescr.10104 = STRING: GigabitEthernet1/0/4 IF‐MIB::ifDescr.10105 = STRING: GigabitEthernet1/0/5 …….

snmpwalk ‐v 2c ‐c admmon 10.254.0.24 1.3.6.1.2.1.2.2.1.7 IF‐MIB::ifAdminStatus.1 = INTEGER: up(1) IF‐MIB::ifAdminStatus.99 = INTEGER: up(1) IF‐MIB::ifAdminStatus.5001 = INTEGER: up(1) IF‐MIB::ifAdminStatus.5002 = INTEGER: up(1) IF‐MIB::ifAdminStatus.10101 = INTEGER: up(1) IF‐MIB::ifAdminStatus.10102 = INTEGER: up(1) …..

snmpwalk ‐v 2c ‐c admmon 10.254.0.24 1.3.6.1.2.1.2.2.1.8 IF‐MIB::ifOperStatus.1 = INTEGER: down(2) IF‐MIB::ifOperStatus.99 = INTEGER: up(1) IF‐MIB::ifOperStatus.5001 = INTEGER: up(1) IF‐MIB::ifOperStatus.5002 = INTEGER: up(1) IF‐MIB::ifOperStatus.10101 = INTEGER: down(2) IF‐MIB::ifOperStatus.10102 = INTEGER: up(1) ….

Página 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 búsqueda del puerto en concreto que queremos monitorizar. El comando quedaría de la siguiente forma: 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 discriminación dependiendo si queremos el estado operacional o administrativo, como con los puertos Ethernet, y devolveremos el valor formateado para Centreon El comando quedaría de la siguiente forma: 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

Página 58 de 135


7 Implementación de la monitorización 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 también servicios que hay en ellos como páginas Web, bases de datos… Dado que de Sistemas ya existía una monitorización previa, reutilizaremos el material que podamos para esta nueva monitorización con FAN. Vamos a coger los archivos de configuración antigua de Nagios (service.cfg, hosts.cfg, groups.cfg) y sacaremos la información que podamos con ellos para utilizarla. Tengamos en cuenta que los archivos de configuración de la monitorización antigua de Nagios no podemos utilizarlos sin más en la nueva monitorización, aunque sea también Nagios, ya que han de pasar a través de Centreon, esto se debe a que el flujo de la información contenida en los archivos de configuración va de Centreon a Nagios y no de Nagios a Centreon.

7.1 Arquitectura de la monitorización Sistemas Llegado a este punto donde se va a empezar a implementar la monitorización 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 monitorización de comunicaciones, y no queremos rehacer el trabajo realizado hasta ahora, se vuelve a estudiar las posibilidades que tenemos para realizar la monitorización de Sistemas. Tenemos las siguientes opciones:

Página 59 de 135


1. Realizar la monitorización 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 opción, realizar la monitorización en un poller nuevo:

Monitorizaciones separadas, tenemos una configuración para cada monitorización, en caso de fallo en el sistema solo afectará a la monitorización 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 monitorización nueva. Para la segunda opción, 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 opción más satisfactoria, con ella podremos ver las 2 monitorizaciones desde la misma maquina con la interfaz de Centreon, las configuraciones estarán separadas, por lo que los cambios que se hagan solo afectarán a la configuración de la monitorización a la que afectan y ambas compartirán la misma base de datos.

Página 60 de 135


7.2 Instalación del poller de Sistemas Una vez se ha decidido por una monitorización distribuida vamos a instalarla en el nuevo servidor. Para realizar una instalación 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 Implementación de Host en Sistemas La monitorización de Sistemas, como ya se dijo anteriormente, ya estaba realizada, por lo que parte del trabajo que se ha hecho será reutilizado.

Página 61 de 135


Los Host de sistemas los podemos encontrar en la configuración antigua de Nagios, en el archivo host.cfg, así pues exploraremos el archivo e iremos sacando uno a uno los nombres, la dirección 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 añadir estos Hosts a Centreon, en lugar de añadirlos uno por uno y creándolos nuevos como se hizo con Comunicaciones, utilizaremos la posibilidad que nos da Centreon de cargar los hosts desde los archivos de configuración de Nagios. Cargar los host desde los archivos de configuración tiene las siguientes ventajas:

Es la forma más rápida de añadir nuevos Hosts, ya que cargaremos todos a la vez.

Sin fallos de transcripción, ya que no tenemos que meter datos manualmente. Si alguno de los host introducidos de esta forma ya existiera, este no sufriría

cambios, y el mismo Centreon omitiría el Host introducido. Pero también hay que tener en cuenta varias cosas antes de cargar la configuración:

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 configuración 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 Implementación de los servicios en Sistemas

7.4.1 Identificación de servicios Los servicios que hay que implementar para Sistemas serán los mismos que tenemos en la configuración previa de Nagios más alguno nuevo que se tendrá que añadir.

Página 62 de 135


También 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 críticos Servicio Warning Critical UR_HTTP Tiempo de respuesta

alto (10 segundos) No se establece conexión

UR_HTTPS Tiempo de respuesta alto (10 segundos)

No se establece conexión

UR_CERT 1 día para expirar el certificado

Certificado expirado

UR_ORACLE_LOGUIN ------- No se establece conexión

UR_CONNECTION_FIREWALL 94% de conexiones 97% de conexiones UR_TUNEL_DIALNET ------- No hay conexión UR_PROCESS ------- Proceso no existe UR_POP3S 10 correos 50 correos UR_TCP ------- Sin conexión tras 10

segundos UR_SMTP Tiempo de respuesta

alto (tiempo por defecto)

No responde

UR_SMTP_SEND Tiempo de respuesta alto (tiempo por defecto)

No responde

UR_SSMTP_SEND Tiempo de respuesta alto (tiempo por defecto)

No responde

UR_DNS ------ El DNS no responde UR_IMAP ------ No responde UR_FTP ------- No hay conexión UR_VIRTUAL_HOST Tiempo de respuesta

alto El servidor no escucha en el puerto

Página 63 de 135


7.5 Implementación 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 cuánto tiempo falta y lanzando un aviso dependiendo de ese tiempo. El comando quedaría de la siguiente forma: 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 número 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 número máximo de conexiones que queremos que el servidor tenga antes de enviarnos una alerta. Se realizará una comparación y se devolverá un valor porcentual que nos indica el porcentaje de conexiones realizadas respecto al máximo introducido. El comando quedaría de la siguiente forma: ur_check_connections.sh HOSTADDRESS $ARG1$ $ARG2$ $ARG3$ $ARG4$ $ARG1$: Community $ARG2$: Límite máximo de conexiones $ARG3$: Valor warning en porcentaje

Página 64 de 135


$ARG4$: Valor de crítico 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 túnel permanente con la fundación 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 túnel. Los valores que nos puede devolver son los siguientes:

3, para túnel activo 131, para túnel caído Cualquier otro número, desconocido

Una vez realizada la consulta devolveremos el estado del servicio dependiendo del valor obtenido. El comando quedaría de la siguiente forma: ./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 páginas 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 página web.

Página 65 de 135


if [ $(netstat ‐an | grep $HOSTVIRTUAL:$PUERTO | grep LISTEN |wc ‐l) ‐ne 1 ]; then echo "HTTP CRITICAL el servidor no escucha las peticiones" exit $STATUS_CODE_CRITICAL fi

A continuación, si el servidor escucha las peticiones correctamente, ejecutaremos el comando check_http para comprobar el estado de la página web.

if [ $PUERTO ‐eq 80 ]; then exec /etc/snmp/commands/check_http ‐I "$HOSTVIRTUAL" ‐p "$PUERTO" ‐u "$WEB" ‐r

"$CADENA" else echo "HTTP OK el servidor escucha las peticiones" 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 redirección 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.

#Conseguimos el estado del host virtual if [ $PUERTO ‐ne 80 ]; then STATUS_VALUE=$(echo $VALOR_RETORNO|cut ‐d" " ‐f5) VALOR_RETORNO=$(echo $VALOR_RETORNO | cut ‐d":" ‐f4) else STATUS_VALUE=$(echo $VALOR_RETORNO | cut ‐d" " ‐f5 | cut ‐d":" ‐f1) VALOR_RETORNO=$(echo $VALOR_RETORNO | cut ‐d":" ‐f5) fi #Discriminamos segun el valor del estado para el servicio de Centreon case $STATUS_VALUE in "OK" ) echo $VALOR_RETORNO exit $STATUS_CODE_OK ;; "CRITICAL" ) echo $VALOR_RETORNO

Página 66 de 135


exit $STATUS_CODE_CRITICAL ;; "WARNING" ) echo $VALOR_RETORNO exit $STATUS_CODE_WARNING ;; * ) echo $VALOR_RETORNO exit $STATUS_CODE_ERROR ;; esac

Configuración 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 serán 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 después al puerto 443. En el archivo snmp.conf del servidor balanceado hay que añadir una línea por cada una de las comprobaciones que queremos realizar. La mayoría de los host virtuales tendrá dos líneas, una para el puerto seguro 443, y otra para el no seguro 80. La línea tendrá este formato: exec OID nombre-del-OID /compilador /comando/a/ejecutar parámetros 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 parámetros 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"

Página 67 de 135


UCD-SNMP-MIB::ucdavis.129.100.1 = INTEGER: 0 UCD-SNMP-MIB::ucdavis.129.101.1 = STRING: "el servidor escucha las peticiones" UCD-SNMP-MIB::ucdavis.129.102.1 = INTEGER: 0 UCD-SNMP-MIB::ucdavis.129.103.1 = "" Podemos ver cómo 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 opción se cree la más 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 Informático 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: Dirección IP del servidor -v : versión 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:

Página 68 de 135


check_centreon_snmp_remote_storage -H $HOSTADDRESS$ -n -d $ARG1$ -w $ARG2$ -c $ARG3$ -C $ARG4$ -v 2 -H: Dirección IP del servidor -n -d: El nombre de la partición -w: Valor de warning -c: Valor crítico -C: Community del SNMP -v 2: versión 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$ -H: Dirección IP del servidor -C: Community del SNMP -v : versión de SNMP -w: Valor de warning -c: Valor crítico

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$ -H: Dirección IP del servidor -v: versión de SNMP -C: Community del SNMP -p: Nombre del proceso

Página 69 de 135


8 Mejoras del Sistema de monitorización

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 Localización Servidor comunicaciones Descripción

En esta web se introducirán los datos de autor y los cambios realizados en el sistema y se le dará al botón aceptar para crear el backup

Archivo Cogernota.php.php Resumen Recogida de datos Localización Servidor de comunicaciones

Página 70 de 135


Descripción Con este archivo se recogerán los datos de autor y cambios

introducidos y se mandara realizar las backup de comunicaciones y sistemas

Archivo centreon-completo-backup.sh Resumen Ejecución de script para la realización de backups Localización Servidor de comunicaciones Descripción Se realizan los comandos para ejecutar los 2 script de backups Archivo Comunicaciones-nagios-backups.sh Resumen Creación de backup de comunicaciones Localización Servidor de comunicaciones Descripción Se realiza un archivo comprimido con los archivos de

configuración de Centreon, Nagios y NagVis y se guardan en el servidor de comunicaciones

Archivo Sistemas-nagios-backup-remoto.sh Resumen Ejecución remota de backup Localización Servidor de comunicaciones Descripción Ejecutamos remotamente el script de backup de Nagios de sistemas Archivo Sistemas-nagios-backup-.sh Resumen Creación de backup de sistemas Localización Servidor de sistemas Descripción Se realiza un archivo comprimido con los archivos de

configuración 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 Informático para que los introduzca dentro de la política de backup corporativa.

8.2 Mapas de red Para realizar los mapas de red utilizaremos el programa NagVis. Con los mapas además de ver la distribución de los equipos, podremos ver qué servicios o Host están caídos. Esta información 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 dónde está la información 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, cuántos hijos y padres del Host nos ha de mostrar…

Página 71 de 135


8.2.1 Mapas de la monitorización de comunicaciones Los mapas de red que necesitemos los crearemos con el programa Nagvis. El criterio para realizar los mapas será según su geografía. Tendremos un mapa por cada edificio del campus, con lo que nos quedan los siguientes mapas:

REC (rectorado) CPD DEP (departamental) FUR (Fundación) FIL ( Filologías) CCT-ATRIO CCT-ITA CCT-QMC QUI ( Quintiliano) BIB (Biblioteca) AMP (Ampliación) PLD (Polideportivo) VIV (Vives)

Crearemos un mapa general donde ver la conexión que tienen los distintos edificios entre sí, llamado Campus. También 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 Fundación Mapa de Filologías Mapa CCT-ATRIO Mapa CCT-ITA Mapa CCT-QMC Mapa Quintiliano Mapa Biblioteca Mapa Ampliación Mapa Polideportivo Mapa Vives

A continuación mostramos 2 mapas, el más general (el campus) y uno más concreto (rectorado) como ejemplo.

Mapa del Campus

Página 72 de 135


Página 73 de 135


Mapa del Rectorado

8.2.2 Mapas de la monitorización 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 monitorización de las páginas Web alojadas en los Host virtuales. Mapa de Sistemas

Página 74 de 135


Mapa de Host virtuales

Observaciones En las imágenes 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.

Página 75 de 135


Durante la realización 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 configuración de ‘default’ y no encontrara los datos. Para solucionarlo tuvimos que realizar un nuevo backend dándole los parámetros de comunicaciones. Los mapas están realizados con la función de ‘automapa’ que tiene Nagvis. Esta utiliza relaciones de padre e hijo, estas relaciones nos las da el responsable del Servicio Informático 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 añadía un nuevo host al sistema de monitorización.

Página 76 de 135


9 Pruebas realizadas en la monitorización Durante el proyecto se han realizado algunas pruebas para asegurarnos del correcto funcionamiento del sistema, estas pruebas se realizaron sobre el sistema de monitorización y sobre los scripts o servicios implementados. Las pruebas realizadas para los script, han sido pruebas de ensayo y error, por lo que se hacían a cada momento para verificar que el script nos daba el resultado deseado. Las pruebas para el sistema fueron realizadas mediante máquinas virtuales con el programa VMware. Antes de realizar la instalación en el servidor, se realizó la instalación en una máquina virtual, así se pudieron comprobar que funcionaban todos los pasos de la instalación.

Las pruebas que se realizaron fueron las siguientes

Instalación central Instalación distribuida Actualizar la plataforma FAN Pruebas en los servicios Realización de copias de seguridad Demonios caídos

Instalación Central

Página 77 de 135


Durante la instalación de FAN como una máquina central que incluye todo (Centreon, Nagios, Base de datos) Descripción Instalación de FAN central Resultado esperado Instalación correcta y funcional Resultado obtenido Instalación correcta y funcional Observaciones Ningún tipo de problema Instalación distribuida Se realizó una instalación distribuida con las máquinas virtuales. Para ello necesitamos dos máquinas virtuales, una donde se instaló el FAN Central y otra donde se instaló el poller de Nagios Descripción Instalación de FAN central Resultado esperado Instalación correcta y funcional Resultado obtenido Instalación correcta y funcional Observaciones Dificultades para que FAN Central detectara el poller de

Nagios. Problemas al actualizar FAN Actualización de FAN Para poder realizar la instalación distribuida se tiene que actualizar FAN, por ello se probó a actualizar FAN en una máquina virtual Descripción Actualización de FAN Resultado esperado Actualizado a la última versión, 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

actualización se completa con éxito Pruebas en servicios Durante la realización de los script estos se fueron probando en la línea de comando, comprobando su correcto funcionamiento. Cabe destacar las pruebas realizadas con los servicios para los Host Virtuales. Descripción Consulta SNMP a los OID creados Resultado esperado Dato obtenido correctamente mediante consulta SNMP Resultado obtenido Dato obtenido correctamente Observaciones En algún caso la consulta SNMP no respondía, esto se debía

a un error de transcripción al configurar el archivo snmpd.conf en los servidores

Pruebas de servicios Windows

Página 78 de 135


Probaremos los distintos servicios que se tienen que realizar en Windows, viendo que funcionan correctamente todos Descripción Comprobación de servicios Windows Resultado esperado Obtención de dato de la consulta SNMP a servidor

Windows Resultado obtenido Obtención 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 realización de copias de seguridad Descripción Realización de copias de seguridad Resultado esperado Archivos comprimidos de la configuración 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 caídos 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

Descripción El demonio de Nagios se para Resultado No hay monitorización 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 Relación con Centreon No detecta el poller, y no muestra la monitorización Descripción El demonio de Apache se para

Página 79 de 135


Página 80 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 monitorización Relaciones con MySQL No le afecta podemos seguir usando el SGBD Relación con Centreon No podemos acceder la interfaz web de Centreon Descripción El demonio de NDO se para Resultado Los datos de la monitorización no se guardan Relaciones con Nagios No le afecta, sigue monitorizando Relaciones con Apache No le afecta sigue funcionando Relaciones con MySQL Sigue funcionando pero no recibe datos Relación con Centreon Funciona correctamente Descripción El demonio de MySQL se para Resultado Perdemos acceso a la base de datos Relaciones con Nagios No le afecta, sigue monitorizando Relaciones con Apache No le afecta Relaciones con NDO No puede almacenar los datos Relación con Centreon Vemos la monitorización, pero no podemos ver ni crear

gráficos Descripción El demonio de Centreon se para Resultado Perdemos el acceso a Centreon Relaciones con Nagios No le afecta, sigue monitorizando Relaciones con Apache No le afecta Relaciones con NDO No le afecta Relación con MySQL No le afecta


10 Gestión 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 Implementación de Sistemas y Comunicaciones. Esto se debe a la inexperiencia a la hora de realizar la implementación, ya que si se producía algún tipo de error nos podíamos quedar atascados y el proyecto no avanzaba. El siguiente gráfico muestra el tiempo utilizado en cada tarea, y podemos ver cómo la implementación de sistemas y Comunicaciones se ha llevado el 56% del tiempo.

7%7%

5%

16%

56%

5% 2% 2%

Dirección y gestión


Diseño

Analisis del sistema demonitorizción

Implementación de Sistemasy Comunicaciones

Pruebas

Manual de usuario

Memoria

Concretamente este tiempo extra se ha utilizado en las tareas de Instalación, Implementación de servicios, plugins y Servicios Windows, además del cambio de diseño de la arquitectura del sistema, que nos hizo realizar una nueva instalación de la herramienta en otro servidor, con los problemas de conectividad que conllevó realizarla. También 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 también conlleva un tiempo que no se ha podido usar en otras tareas.

Página 81 de 135


0

20

40

60

80

100

120

140

160

180

200

Tiempo real

Tiempo estimado

Tiempo real 105 50 195 112 140

Tiempo estimado 44 50 88 52 50

InstalacionImplementación host

Implementación de

servicios

Implementación de plugins

Implementación

windows

Como muestra el grafico más detallado de las tareas en la implementación del sistema, vemos como las tareas de instalación, implementación de servicios, plugins y servicios Windows, nos han llevado mucho más tiempo del estimado, mientras que la de implementación de host ha sido el tiempo estimado, ya que ha sido una tarea sin complicaciones. Esta mala estimación se debe principalmente a que el proyecto trata sobre conocimientos que se desconocían y los cuales han tenido que ser aprendidos durante la realización del proyecto. Además hay que sumar la inexperiencia del alumno en la solución de los problemas que han podido surgir durante la implementación del sistema de monitorización. El diagrama de Gantt que se muestra a continuación se ve el tiempo real dedicado al proyecto.

Página 82 de 135


Página 83 de 135


10.1 Conclusiones Al empezar la beca de colaboración con el servicio informático, ya tenía planteado otro proyecto, parecido al resto de trabajos que realizan otros compañeros de la carrera, pero fue el trabajar con algo nuevo, algo que desconocía, las redes y servidores, las herramientas de monitorización, 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 común respecto a los demás, y por ello creo que es atractivo para un estudiante. Durante su realización he trabajado en un entorno real, el Servicio informático de la UR, teniendo todos los problemas que se pueda tener en un entorno nuevo de trabajo añadiendo además 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 periódicas con el jefe de proyecto en las que se ha ido informando del avance del proyecto, solucionando problemas y viendo posibles mejoras que se podían 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 exposición oral, algo, a mi parecer, muy importante en nuestra profesión. 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, además 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. También he tenido que mejorar mis conocimientos con BBDD de MySQL, virtualización a la hora de realizar las pruebas y programación en la realización de los Script para los servicios. Actualmente el sistema de monitorización está listo para ser utilizado, y coexiste con el antiguo sistema de monitorización. 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 monitorización quiere realizar cuanto antes. En conclusión, 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 realización, los cuales en un entorno controlado como el aula no somos conscientes de ellos, a todo esto hay que añadirle la satisfacción que da el realizar un proyecto real el cual va a ser utilizado y no solamente presentado como ejercicio academico.

Página 84 de 135


10.2 Informe del supervisor de la monitorización D. Ignacio Lasheras Herrero Técnico de sistemas, comunicaciones y seguridad del Servicio Informático de la Universidad de la Rioja. De mis consideraciones: Por medio de la presente me permito expresar mi alto grado de satisfacción en el software de monitorización FAN implantado por Eduardo Laborda en el Servicio Informático de La Universidad de La Rioja. Se han cumplido las expectativas y se ha mejorado la calidad del servicio de la monitorización. Se han superado los requisitos iniciales de la monitorización y se han completado hasta llegar a formar un sistema de monitorización completo y eficiente. Durante su tiempo en el Servicio Informático ha realizado el mantenimiento de la monitorización satisfactoriamente y actualmente el software está listo para usarse al 100%. Estoy completamente satisfecho por el trabajo realizado por Eduardo Laborda.

Atentamente, Ignacio Lasheras

Página 85 de 135


11 Bibliografía Toda la información utilizada para realizar este proyecto ha sido obtenida mediante Internet. Paginas Web para la documentación: 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

Página 86 de 135

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


12 Anexos

12.1 NRPE y SNMP

12.1.1 NRPE NRPE es un plugin de Nagios que permite al sistema una monitorización remota mediante secuencias de comandos que están alojadas en los sistemas a monitorizar. Con ello podemos monitorizar los recursos de supervisión, como el uso del disco, la carga del sistema o el número de usuarios actualmente conectados. Nagios lanza el agente periódicamente 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 máquina remota. (Opcionalmente mediante una conexión 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 continuación, devuelve los resultados de la verificación 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 sería capaz de monitorizar nada.

Los chequeos pueden ser directos o indirectos:

Página 87 de 135


Chequeo directo: El uso más 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 “públicos” o que no son accesibles directamente por el servidor a monitorizar. Por ejemplo si queremos monitorizar una página 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 Administración de Red) El Protocolo Simple de Administración de Red o SNMP (del inglés Simple Network Management Protocol) es un protocolo de la capa de aplicación que facilita el intercambio de información de administración entre dispositivos de red. Permite a los administradores supervisar el funcionamiento de la red, buscar y resolver sus problemas, y planear su crecimiento.

Página 88 de 135


Las versiones de SNMP más utilizadas son SNMP versión 1 (SNMPv1) y SNMP versión 2 (SNMPv2). Componentes básicos Una red administrada a través de SNMP consiste de tres componentes claves:

Dispositivos administrados Agentes Sistemas administradores de red (Network Management Systems, NMS’s).

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 información de administración, la cual es puesta a disposición de los NMS’s 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 módulo de software de administración de red que reside en un dispositivo administrado. Un agente posee un conocimiento local de información de administración (memoria libre, número de paquetes IP recibidos, rutas, etcétera), la cual es traducida a un formato compatible con SNMP y organizada en jerarquías. Un sistema administrador de red (NMS) ejecuta aplicaciones que supervisan y controlan a los dispositivos administrados. Los NMS’s proporcionan el volumen de recursos de procesamiento y memoria requeridos para la administración de la red. Uno o más NMS’s deben existir en cualquier red administrada. Comandos básicos Los dispositivos administrados son supervisados y controlados usando cuatro comandos SNMP básicos: lectura, escritura, notificación 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 notificación es usado por los dispositivos administrados para reportar eventos en forma asíncrona a un NMS. Cuando cierto tipo de evento ocurre, un dispositivo administrado envía una notificación al NMS. Las operaciones transversales son usadas por el NMS para determinar qué variables soporta un dispositivo administrado y para recoger secuencialmente información en tablas de variables, como por ejemplo, una tabla de rutas.

Página 89 de 135


Base de información de administración SNMP (MIB) Una Base de Información de Administración (Management Information Base, MIB) es una colección de información que está organizada jerárquicamente. Las MIB’s son accedidas usando un protocolo de administración de red, como por ejemplo, SNMP. Un objeto administrado (algunas veces llamado objeto MIB, objeto, o MIB) es uno de cualquier número de características específicas de un dispositivo administrado. Los objetos administrados están compuestos de una o más 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 múltiples instancias de objeto relacionadas que están agrupadas conjuntamente en tablas MIB. Un identificador de objeto (object ID) identifica únicamente a un objeto administrado en la jerarquía MIB. La jerarquía MIB puede ser representada como un árbol con una raíz anónima y los niveles, que son asignados por diferentes organizaciones.

El árbol MIB ilustra las variadas jerarquías asignadas por las diferentes organizaciones Los identificadores de los objetos ubicados en la parte superior del árbol pertenecen a diferentes organizaciones estándares, mientras los identificadores de los objetos ubicados en la parte inferior del árbol son colocados por las organizaciones asociadas.

Página 90 de 135

http://commons.wikimedia.org/wiki/File:Imagen2.JPG�


Los vendedores pueden definir ramas privadas que incluyen los objetos administrados para sus propios productos. Las MIB’s que no han sido estandarizadas típicamente están localizadas en la rama de los árboles. El objeto administrado atInput podría 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 corazón 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 información 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 línea de órdenes. Su forma más básica permite pasar de un OID a la variable que representa (representación textual): #snmptranslate .1.3.6.1.2.1.1.3.0 SNMPv2-MIB::sysUpTime.0 También 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 automáticamente y se detiene cuando devuelve resultados que no están en el rango del OID especificado originalmente. Por

Página 91 de 135


ejemplo, si quisiéramos obtener toda la información almacenada en el grupo system del MIB de una máquina podríamos 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

Página 92 de 135


12.2 Manual de usuario Instalación de la herramienta de monitorización Preparación del servidor El equipo donde se instalara la herramienta FAN Nagios es el servidor de monitorización (HP PROLIANT DL 380 G4), este servidor tenía instalado previamente una instancia de Nagios, guardaremos sus archivos de configuración para una posible reutilización mas adelante.

Características 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 instalación de FAN Nagios se creara un raid 0+1.

El disco duro le daremos las siguientes particiones, esto se debe a una decisión 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 monitorización tendremos que fijarnos cuanto ocupa la base de datos, y si el volumen de datos aumenta muy rápidamente por si es necesario ampliar el disco duro.

Página 93 de 135


Instalación software La instalación de FAN Nagios es cómoda e intuitiva, solo necesitamos meter el CD de instalación con la ISO que descargamos de la página Web de FAN Nagios y seguir los pasos que nos indica el asistente de instalación. El sistema operativo que se instala con FAN Nagios es un CentOS. Lo primero que nos indica es que queremos instalar dándonos las siguientes opciones:

Instalación centralizada, todo en un mismo servidor Instalación distribuida:

o FAN central: Instalación de Centreon con Nagios. o FAN poller: Instalación de las distintas instancias de Nagios o FAN databases: Instalación de la base de datos

Una vez seleccionado el tipo de instalación le indicaremos las particiones y los datos de red para que el equipo tenga conexión de red. Durante al instalación nos pedirá que le demos una contraseña para el usuario administrador del sistema (root).

Página 94 de 135


Instalación 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. Podríamos 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 ningún 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 continuación:

Comando: yum install postfix

Configuración de Postfix

La configuración 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 envío

de las alertas son los siguientes:

Página 95 de 135


Datos del servidor: Dirección: xxxx.unirioja.es Puerto: 587 Datos de la cuenta: Usuario: xxxxxx-ext Contraseña: [CONTRASEÑA] Cuenta: [email protected]

Como queremos que Postfix se inicie automáticamente cada vez que se arranque la

máquina, 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 gráfico gedit o el editor de consola vi, dependiendo de dónde nos encontremos.

Comandos utilizados: Modo gráfico: gedit [NOMBRE_ARCHIVO] Modo consola: vi [NOMBRE_ARCHIVO]

Página 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 continuación:

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 continuación:

Archivo: /etc/postfix/sasl_passwd Contenido: [xxxx.unirioja.es]:587 xxxxxx-ext:[CONTRASEÑA]

Página 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 continuación:

Archivo: /etc/postfix/generic Contenido: root [email protected] nagios [email protected]

La primera línea hacer que todos los correos enviados por consola (usuario root) se

envíen por la dirección deseada mientras que la segunda hace lo mismo pero con las alertas que envía Nagios (usuario Nagios).

Una vez editados los archivos vamos a darles los permisos correctos y a generar las

bases de datos correspondientes.

Comandos utilizados: 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. Sólo 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.

Página 98 de 135


Comandos utilizados: 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 sólo queda reiniciar la máquina. Tras el reinicio, podemos comprobar si el

servicio se inicia al arrancar y también podemos comprobar si podemos enviar un mail por consola.

Comandos utilizados: Reiniciar la máquina # 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 opción de instalar poller, con esto se instalara automáticamente lo que necesitamos, como una instalación normal.

Página 99 de 135


Una vez instalado, actualizamos, es muy importante actualizar en este punto, ya que no todas las versiones de FAN admiten una configuración distribuida, por ello se ha de actualizar a la última versión y así evitar estos problemas. (Ver apartado Actualización 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 también se pueden ver en la documentación 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 comunicación vía ssh, sin password, entre FAN central y el poller. En la Web de Centreon, ir a Configuración > Centreon > Poller y añadir uno

con los datos de nuestro nuevo Nagios. En Configuración > Centreon > ndomod añadir 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

Página 100 de 135

http://www.fullyautomatednagios.org/wordpress/configure-distributed-monitoring/

http://www.fullyautomatednagios.org/wordpress/configure-distributed-monitoring/

http://www.r71.nl/kb/technical/345-centreon-add-a-poller


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 configuración están todos configurados

correctamente (nagios.cfg, ndomod.cfg, broker). Activar la configuración 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 instalación y configuración del poller de Sistemas Antes de realizar la instalación en los servidores se hizo una instalación de pruebas en maquinas virtuales para comprobar que todo funcionaba correctamente, aun así, durante la instalación del poller de Sistemas se han encontrado diversos problemas, los enumeramos a continuación

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 comunicación entre el poller y Centreon.

Estos problemas retrasaron el avance del proyecto, ya que al no poder realizar la instalación no se podía avanzar en la implementación de la monitorización. 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 necesitábamos.

Actualizando Nagios a la versión 3.3.1, con la cual ya se puede realizar una configuración distribuida.

Página 101 de 135


Realizar las claves ‘rsa’ y pasarlas manualmente a cada maquina para poder

realizar la conexión ssh sin password. Para conseguir actualizar se añadieron los repositorios de FAN nuevos, ya que

los que vienen con la instalación estaban obsoletos y no se podía 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 versión, NDOUtils no era capaz de establecer comunicación con Nagios.

Dar los permisos necesarios al usuario Nagios, no solo en el servidor central, sino también en el del poller de sistemas.

Creación de host, servicios, comandos, usuarios, plantillas y host Group en Centreon Host Para añadir un Host en Centreon tendremos que ir a Configuration>Host>Add le daremos al botón y nos saldrá un formulario el cual tendremos que rellenar y le daremos a el botón ‘Save’ para guardar el nuevo Host. A continuación se detalla la información que se necesita rellenar para crear el Host Información 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: dirección del Host (este dato lo dejaremos en blanco) 4. SNMP community: versión 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

Propiedades de chequeo del Host 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

Página 102 de 135


13. Max Check Attempts: intentos máximos 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 notificación si el Host

sigue caído 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 caído o

inalcanzable hasta que se manda la primera notificación.

Relaciones Linked Service Templates: plantilla para el servicio básico para el Host.

Página 103 de 135


Otras opciones que podemos realizar con los Host son las de borrar, modificar, modificación masiva, habilitar, deshabilitar. Para hacer cualquiera de ellas seleccionaremos los Host y le daremos a la opción que queremos realizar

Servicios Para añadir un servicio en Centreon tendremos que ir a Configuration>Services, seleccionaremos el Host al cual le queremos añadir un servicio y le daremos al botón ‘Add’, nos saldrá un formulario el cual tendremos que rellenar y le daremos a el botón ‘Save’ para guardar el nuevo servicio A continuación se detalla la información que se necesita rellenar para crear el servicio Información 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

Página 104 de 135


Estado del servicio 18. Is volatile: si el servicio es volátil, 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 máximos 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 notificación si el Host

sigue caído 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 caído o

inalcanzable hasta que se manda la primera notificación.

Página 105 de 135


Relaciones Linked to host template: plantilla para el servicio básico para el Host. Grupos de host Para crear un host Group iremos a Configuration>Hosts>Hosts Group y le daremos al botón de ‘Add’ A continuación se detalla la información que se necesita rellenar para crear el Host Group Información general Host Group Name: nombre del Host Group Alias: alias del host group SNMP Community & version: versión de SNMP y su community que utiliza por defecto el Host Group Relations Linked Hosts: lista de host pertenecientes al Host Group

Página 106 de 135


Usuarios Para crear un usuario nos iremos a Configuration>Users y le daremos al botón Add Añadir usuario

Página 107 de 135


Los campos obligatorios son los siguientes Full Name : nombre del usuario Alias/Login: alias del usuario Email: correo electrónico del usuario. El resto de datos no es necesario rellenarlos.

Página 108 de 135


En esta pestaña 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 botón Add, a continuación de daremos los accesos a los recursos y a los menús que queramos, y después le añadiremos los usuarios que queremos que tengan estos permisos.

Página 109 de 135


Comando Para añadir un comando iremos a Configuration>Commands y le daremos al botón Add para añadir un usuario (también se puede borrar, duplicar…)

Command Name: nombre del comando Command type: tipo de comando Command Line: línea de comando a ejecutar Argument Example: argumentos de ejemplo para el comando Argument Description: descripción de los argumentos del comando

Página 110 de 135


12.3 Actas de reunion

12.3.1 Acta 1

Proyecto: Adecuación, mejora y optimización de la plataforma de monitorización de red y sistemas en la UR con herramientas de software libre.

Fecha: 04-10-2011

Lugar: Empresa - Lugar

Hora inicio: 11:00

Hora finalización:

12:00

Asistentes: Asistente Empresa Fernando Ríos Servicio Informático de

la UR Ignacio Lasheras Servicio Informático de

la UR Eduardo Laborda

Orden del día: Presentación de la beca e información del trabajo a realizar

Temas tratados:

1. Presentación de la Beca

Se trataran los horarios, se indicara quienes son los responsables, y cuál es el lugar de trabajo

2. Monitorización de la red de la UR

Se realizara una explicación de que trabajo se quiere realizar durante la realización de la beca

Temas pendientes:

Tema Responsables Fecha resolución Realizar una presentación de la herramienta de monitorización

Eduardo Laborda 10-10-2011

Página 111 de 135


12.3.2 Acta 2


Fecha: 10-10-2011


Hora inicio: 11:00

Hora finalización:

12:00




Orden del día: Presentación de la herramienta de monitorización (FAN Nagios)

Temas tratados:

1. Presentación en FAN Nagios

Se presenta con un Power point el software de monitorización (FAN Nagios)

Temas pendientes:

Tema Responsables Fecha resolución Realizar instalación de FAN Eduardo Laborda

Página 112 de 135


12.3.3 Acta 3


Fecha: 14-10-2011


Hora inicio: 11:00

Hora finalización:

13:00




Orden del día: Fijar primeros pasos para la implementación de la monitorización

Temas tratados:

1. Recolección de información

Se empiezan identificar algunos usuarios y Host, para realizar sus plantillas y añadirlas a Centreon

2. Identificación de servicios

Se comenta por encima algo de los servicios que tendremos que monitorizar

3. Backup

Se comenta la posibilidad de realizar algún tipo de backup mas adelante para salvar la monitorización

Temas pendientes:

Tema Responsables Fecha resolución Añadir las plantillas, usuarios y Host comentados en la reunión a Centreon

Eduardo Laborda

Página 113 de 135


12.3.4 Acto 4


Fecha: 14-11-2011


Hora inicio: 11:00

Hora finalización:

13:00




Orden del día: Comprobar avance del proyecto

Temas tratados:

1. Comprobación 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. Gráficos en Centreon

Se encuentra un problema en la visualización de los gráficos

3. Nuevos servicios y Hosts

Se amplía la lista de Hosts y servicios

4. Backup

Se comenta la realización de una mejora en la Web para realizar el backup de la monitorización

Temas pendientes:

Tema Responsables Fecha resolución Añadir las plantillas, Host y servicios comentados en la reunión a Centreon

Eduardo Laborda

Añadir las descripciones a los Host Group

Eduardo Laborda

Definir los servicios para Switches y Eduardo Laborda

Página 114 de 135


servidores Solucionar el problema en la visualización de los gráficos en Centreon

Eduardo Laborda

Página 115 de 135


12.3.5 Acta 5


Fecha: 29-11-2011


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Reasignación 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. Reutilización de configuración de Nagios

La configuración antigua de Nagios se puede reutilizar, se ha de mirar que partes se puede reaprovechar.

Observaciones:

Comentamos cómo funciona la carga de los archivos de configuración 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 configuración de Nagios, la próxima vez que se cargue la configuración de Centreon esos cambios se borrarán. Temas pendientes:

Página 116 de 135


Tema Responsables Fecha resolución Explorar archivos de configuración antigua y extraer los datos reutilizables

Eduardo Laborda

Asignar los nuevos nombres a las plantillas

Eduardo Laborda

Página 117 de 135


12.3.6 Acta 6


Fecha: 14-12-2011


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Mapas de red

Se habla de que mapas de red son necesarios realizar

Temas pendientes:

Tema Responsables Fecha resolución Continuar con la implementación de los servicios en Centreon

Eduardo Laborda

Empezar a realizar los mapas de red con NagVis

Eduardo Laborda

Página 118 de 135


12.3.7 Acta 7


Fecha: 12-01-2012


Hora inicio: 11:00

Hora finalización:

13:00




Orden del día: Comprobar avance de la monitorización

Temas tratados:



2. Mapas de red

Se enseñan los mapas realizados, se comentan cambios y nuevos mapas a realizar

3. Backup den la Web

Se comenta el añadir un nuevo link en la página Web que nos mande a otra ventana donde realizaremos la backup del sistema de monitorización

4. Cambios en plantillas

Se comenta realizar algún cambio en las plantillas de Host y en los Host Group

Temas pendientes:


Eduardo Laborda

Cambiar los mapas de red con NagVis y realizar los nuevos

Eduardo Laborda

Página 119 de 135


Crear el backup mediante la Web Eduardo Laborda

Página 120 de 135


12.3.8 Acta 8


Fecha: 02-02-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Monitorización de sistemas

La parte de comunicaciones está casi terminada, se comenta como empezar con la monitorización de sistemas

3. Arquitectura del sistema

Se habla de hacer una arquitectura central o distribuida ¿cuál es mejor para nosotros?

Temas pendientes:


Eduardo Laborda

Ver las posibles arquitecturas para la monitorización de Sistemas

Eduardo Laborda

Página 121 de 135


12.3.9 Acta 9


Fecha: 24-02-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Arquitectura del sistema

Se comentan las ventajas de una arquitectura distribuida y se decide realizarla

Temas pendientes:


Eduardo Laborda

Realizar la instalación del nuevo ‘poller’ de sistemas en el nuevo servidor y comunicarla con el servidor Central.

Eduardo Laborda

Página 122 de 135


12.3.10 Acta 10


Fecha: 22-03-2012


Hora inicio: 11:00

Hora finalización:

13:00




Orden del día: Comprobar avance de la monitorización e instalación del ‘poller’

Temas tratados:



2. Instalación del poller de sistemas

Se comentan los errores de conectividad entre el poller de sistemas y Centreon, se intentan buscar posibles soluciones

Temas pendientes:


Eduardo Laborda

Probar las posibles soluciones comentadas en la reunión para que funcione correctamente el poller de Sistemas

Eduardo Laborda

Actualizar la plataforma de monitorización (FAN Nagios)

Eduardo Laborda

Página 123 de 135


12.3.11 Acta 11


Fecha: 04-04-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Configuración de la monitorización de Sistemas

Se comprueba que es lo que se puede reutilizar de la configuración 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:


Eduardo Laborda

Hacer listado de Host y servicios de Sistemas y añadirlos a la configuración

Eduardo Laborda

Cambiar o crear nuevos comandos con SNMP

Eduardo Laborda

Página 124 de 135


12.3.12 Acta 12


Fecha: 17-05-2012


Hora inicio: 11:00

Hora finalización:

13:00





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 añadir en NagVis sobre la monitorización de sistemas

Temas pendientes:


Eduardo Laborda

Añadir los nuevos mapas de NagVis Eduardo Laborda Instalar El cliente de Oracle para poder realizar los servicios de loguin a bases de datos

Eduardo Laborda

Página 125 de 135


12.3.13 Acta 13


Fecha: 31-05-2012


Hora inicio: 11:00

Hora finalización:

13:00





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 página de inicio de los servicios, solo es en la presentación de los mismos, en la configuración no hay presente duplicidad. Investigarlo y comentarlo en la próxima reunión

4. Back Up de NagVis

Se quiere añadir los mapas de NagVis al backup que se realiza, así como la configuración de Sistemas

Temas pendientes:


Eduardo Laborda

Añadir los mapas de NagVis al back up Eduardo Laborda Añadir Sistemas al back up Eduardo Laborda

Página 126 de 135


12.3.14 Acta 14 Proyecto: Adecuación, mejora y optimización de la plataforma de monitorización

de red y sistemas en la UR con herramientas de software libre.

Fecha: 06-06-2012

Lugar: Despacho de María Vico

Hora inicio: 11:00

Hora finalización: 12:00

Asistentes: Asistente Empresa María Vico

Eduardo Laborda

Orden del día: Explicación del proyecto a realizar en la Beca de colaboración

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

Página 127 de 135


12.3.15 Acta 15


Fecha: 15-06-2012

Lugar: Sala de reuniones del Rectorado

Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Servicios de monitorización

Eliminar el servicio ‘ping’ de los Host en los que no sea necesario

3. Error de Centreon

El error encontrado en la reunión 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 solución 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:

Página 128 de 135



Eduardo Laborda

Activar el NSClient++ en un servidor Windows

Eduardo Laborda

Realizar servicios de CPU, RAM, disco, a un servidor Windows mediante NSClient++

Eduardo Laborda

Página 129 de 135


12.3.16 Acta 16


Fecha: 20-07-2012


Hora inicio: 11:00

Hora finalización:

13:00





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:

Tema Responsables Fecha resolución Continuar con la implementación de los servicios Windows en Centreon

Eduardo Laborda

Activar el servicio SNMP en un servidor Windows

Eduardo Laborda

Realizar servicios de CPU,RAM, disco.. a un servidor Windows mediante SNMP

Eduardo Laborda

Página 130 de 135


12.3.17 Acta 17


Fecha: 07-09-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:




Comprobación 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:

Tema Responsables Fecha resolución Continuar con la implementación de los servicios Windows en Centreon

Eduardo Laborda

Realizar los cambios en los mapas de NagVis

Eduardo Laborda

Página 131 de 135


12.3.18 Acta 18


Fecha: 05-10-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Servicios Para host virtuales

Se habla de que son y que se quiere monitorizar de ellos

Temas pendientes:

Tema Responsables Fecha resolución Realizar monitorización de los host virtuales

Eduardo Laborda

Página 132 de 135


12.3.19 Acta 19


Fecha: 30-11-2012


Hora inicio: 11:00

Hora finalización:

13:00





Temas tratados:



2. Servicios para host virtuales

Se comprueba que la monitorización 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 quería realizar para el proyecto, no se van a realizar estos servicios, y será el servicio informático quien se encargue de ponerlos en FAN

Temas pendientes:

Tema Responsables Fecha resolución Realización de memoria Eduardo Laborda

Página 133 de 135




Fecha: 20-02-2013


Hora inicio: 11:00



Eduardo Laborda

Orden del día: Revisión de la Memoria


Temas tratados:

1. Primera revisión de la memoria Se corrigen y se comentan los cambios a realizar en la memoria

Temas pendientes:

Tema Responsables Fecha resolución Redacción de la me memoria y de los cambios mencionados en la reunión

Eduardo Laborda

Página 134 de 135


Página 135 de 135



Fecha: 11-04-2013


Hora inicio: 11:00



Eduardo Laborda

Orden del día: Revisión de la Memoria


Temas tratados:

1. Segunda revisión de la memoria

Se corrigen y se comentan los cambios a realizar en la memoria para finalizarla Temas pendientes:

Tema Responsables Fecha resolución Redacción de la me memoria y de los cambios mencionados en la reunión

Eduardo Laborda

adecuación, mejora y optimización de la plataforma de ... · 3.10.2 pandora ... vmware esx y...

Documents