Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz'

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA Grado en Ingeniería de Computadores Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' Computer network monitoring system. The 'Turismo Andaluz' case Realizado por Laura González García Tutorizado por Julián Ramos Cózar Departamento Arquitectura de Computadores UNIVERSIDAD DE MÁLAGA MALAGA, Octubre 2.014 Resumen Este Trabajo Fin de Grado, describe la implantación de un sistema de monitorización de redes informáticas. Se definirán los principales conceptos de monitorización, y se argumentará la elección de la herramienta finalmente seleccionada para llevarlo a cabo. Detallaremos el proceso de instalación, configuración y puesta en producción. Por último, se mostrará cómo funciona el sistema ya instalado sobre la red informática de la Empresa Pública de Turismo Andaluz, S.A., cubriendo las necesidades de control de sistemas desde su sede principal, sita en Málaga, al resto de provincias andaluzas, donde posee diversas sedes secundarias. Palabras claves: sistemas, monitorización, red, servidores, servicios, nagios, pandora, cacti, gammu, mrtg, nrpe, nsclient+, notificación, alerta – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 5 Abstract The present work describes the deployment of an ICT network monitoring system. We will define monitoring main concepts and will show the reasoning behind the tool selection process. We will give details about installation, configuration and final deployment of the tool. Finally, the paper will present a real installation on the Empresa Pública de Turismo Andaluz, S.A. network, that supports the users monitoring needs from its main site in Malaga to the satellite sites locate on the other seven Andalusian provinces. Keywords: smtp, monitoring, systems, protocols, notification, alert, check_nrpe, check_nt, check_ping – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 6 ÍNDICE 1. INTRODUCCIÓN...................................................................................................11 1.1. Objetivo...............................................................................................................11 1.2. Contenidos de la memoria..................................................................................14 2. MONITORIZACIÓN...............................................................................................17 2.1. Concepto de Monitorización...............................................................................17 2.2. ¿Qué debemos monitorizar?..............................................................................19 2.3. Herramientas de Monitorización.........................................................................21 2.3.1. Comparativa de herramientas......................................................................21 2.3.2 Herramienta seleccionada............................................................................28 2.3.3. Funcionamiento de Nagios..........................................................................30 3. INSTALACIÓN Y CONFIGURACIÓN DE NAGIOS...............................................35 3.1. Tipo de servidor y Sistema Operativo seleccionado..........................................35 3.1.1. Instalación servidor virtual............................................................................37 3.1.2. Configuración servidor virtual.......................................................................39 3.1.3. Instalación dispositivo envío SMS...............................................................41 3.2. Instalación de Nagios.........................................................................................46 3.2.1. Nagios en el Servidor...................................................................................46 3.2.2. Nagios en el cliente......................................................................................57 3.2.2.1. Cliente Nagios para Linux..................................................................57 3.2.2.2. Cliente Nagios para Windows............................................................60 3.2.3. Plugins..........................................................................................................61 3.3. Configurando Nagios..........................................................................................64 3.3.1. hosts.cfg.......................................................................................................65 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 7 3.3.2. services.cfg..................................................................................................66 3.3.3. hostgroups.cfg..............................................................................................71 3.3.4 servicegroups.cfg..........................................................................................72 3.3.5. contacts.cfg..................................................................................................72 3.3.6. contactgroups.cfg.........................................................................................73 3.3.7. timeperiods.cfg.............................................................................................74 3.3.8. templates.cfg................................................................................................75 3.4. Interfaz web........................................................................................................79 3.5. Otras opciones para comprobar estados y alertas............................................85 3.5.1. Complementos para navegadores web.......................................................85 3.5.2. Aplicaciones móviles....................................................................................87 3.6. Aplicaciones adicionales.....................................................................................90 3.6.1. Cacti.............................................................................................................90 3.6.2. Mrtg..............................................................................................................93 4. CASO REAL EN TURISMO ANDALUZ.................................................................97 4.1. Turismo Andaluz, SA.......................................................................................97 4.2. Monitorización red informática TASA..............................................................99 4.3. Servidores / Servicios monitorizados en TASA.............................................103 4.4. Ejemplos de informes presentados por Nagios............................................109 4.5 Tipos de alertas/notificaciones recibidas........................................................111 4.6. Complementos añadidos...............................................................................113 Conclusiones............................................................................................................117 Referencias bibliográficas........................................................................................119 Anexo 1. Plugins de Nagios....................................................................................120 Anexo 2. Ejemplos de plantillas...............................................................................121 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 8 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 9 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 10 1. INTRODUCCIÓN El desarrollo de este proyecto, surge como una necesidad tras años de experiencia en el Área de Sistemas del Departamento Informático. Día tras día, el número de instalación de servidores, servicios, aplicaciones, dispositivos electrónicos,... va aumentando para que la infraestructura tecnológica de la empresa pueda funcionar correctamente. El tiempo que debe destinarse a confirmar que no existen errores o fallos en cualquier sistema, también crece proporcionalmente. Por ello, con más o menos criticidad, es necesario habilitar un sistema que se encargue de la monitorización y un sistema de alertas, para que en caso de que se produzca algún problema, se le notifique al personal responsable. De esta forma, los recursos humanos del departamento pueden dedicarse a otras funciones, al ser descargado de esta continua “vigilancia”. Este mecanismo deberá funcionar de forma autónoma en períodos de 24x7 todos los días del año. 1.1. Objetivo El objetivo principal de este Trabajo Fin de Grado (TFG, a partir de ahora), será la implantación de un robusto sistema de monitorización para la Empresa Pública de Turismo Andaluz, S.A. (TASA, a partir de ahora) que cubra todas las necesidades de control de sus principales sistemas informáticos, electrónica de red y líneas de datos, en las diferentes sedes que tiene actualmente en Andalucía. Para llevar a cabo este proyecto, se realizará un análisis de las herramientas que existen actualmente, para decidir cuál es la más indicada para cubrir sus necesidades y entonces, realizar una exhaustiva descripción del proceso de instalación y configuración. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 11 Este control del estado de los objetos monitorizados se llevará a cabo mediante el intercambio de información entre un servidor central y el resto de sistemas a vigilar. El diálogo se realizará a través de protocolos de comunicación entre los sistemas implicados. A partir de esta información y según se haya indicado en la configuración, qué es lo que debe interpretarse como un error, el servidor principal, deducirá si existe algún problema y qué acción debe llevar a cabo: enviar un email, un SMS, ejecutar alguna acción que corrija el problema. Para llevar a cabo esto, algunos sistemas necesitarán la instalación de algún tipo de software adicional (cliente) para que pueda “hablar” correctamente con el servidor principal y facilitarle la información necesaria, para evaluar si todo está funcionando correctamente. Esto dependerá de lo que deseemos monitorizar en el sistema remoto. No es lo mismo comprobar si un sistema está encendido, que saber la cantidad de memoria RAM que tiene disponible un sistema para trabajar de forma óptima. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 18 2.2. ¿Qué debemos monitorizar? La premisa de la que debemos partir para tomar esta decisión sería: “De qué componentes de mi sistema debería recibir un aviso en caso de que exista algún problema, de tal forma que no deba estar comprobando yo mismo su estado continuamente”. Es decir, aquello que si falla, quiero saberlo cuanto antes para que el problema no derive en otro mayor. Como la naturaleza de todos los componentes de un sistema informático / electrónico es muy distinta, también deberemos tener en cuenta qué aspectos son más críticos que otros. Por ejemplo, desearía recibir un SMS cuando haya una caída en la línea principal de la sede central de la empresa, para avisar a nuestro proveedor de servicio lo antes posible, sin embargo, para el caso en que el espacio libre que tiene un sistema de archivos, dedicado a las copias de seguridad, ha bajado del 20%, con recibir un email de notificación, tendría suficiente y corregirlo una vez esté físicamente en la oficina. Podemos enumerar algunos de los principales objetos que deberían ser monitorizados: Todos los servidores principales: Firewall, Proxy, Correo Electrónico, DNS Todos los servidores de web Todos los switches pertenecientes a la electrónica de red. En concreto los puertos por  donde debamos asegurarnos que existe tráfico de información Todos los routers de líneas de datos (tanto principales como de backups) – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 19 Y de ellos, deberíamos asegurarnos de recibir información en caso de problemas con: Espacio en disco / sistemas de archivos Gestión de memoria Número de procesos activos Número de procesos “zombies” Existencia de ficheros: Tanto de copias de seguridad, como de logs Nivel de carga en CPU Estado de puertos en servidores, para confirmar que realmente están “escuchando” Inodos de los sistemas de archivos con mayor volumen de creación de ficheros Caducidad de certificados web de dominios publicados bajo https Tiempo de actividad del sistema – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 20 2.3. Herramientas de Monitorización Actualmente, existen numerosas herramientas software que se encargan de la monitorización de sistemas. Para llevar a cabo un comparativo entre ellas, nos basaremos en la documentación que nos ofrece la Wikipedia. Si accedemos a ella, podremos encontrar un gráfico, que por sus dimensiones no es posible mostrar aquí, en la que se enumeran todas las herramientas de monitorización que existen, con todas las características que poseen. El enlace a esta imagen es: Referencia a cuadro resumen de comparativo de herramientas: http://es.wikipedia.org/wiki/Anexo:Comparaci %C3%B3n_de_sistemas_de_monitorizaci%C3%B3n_de_redes Por simplificar este comparativo, en nuestro caso, sólo buscaremos entre aquellas herramientas, que siendo OpenSource (Código Abierto, por tanto, sin licencia ni coste económico) y totalmente configurable, nos proporcione los medios necesarios para poder controlar la mayoría de los sistemas. Por no ser motivo de este proyecto, el estudio detallado de dichas herramientas, se realizará una enumeración de las más importantes, indicando sus ventajas e inconvenientes de forma breve. Como se mencionó anteriormente, el desarrollo de este TFG se realizará con una sola de ellas, elección que justificaremos llegado el momento. 2.3.1. Comparativa de herramientas Las herramientas de control de redes se diferencian unas de otras, de cómo realizan el intercambio de información con los dispositivos, la forma en la que la gestionan, la representan y, en caso de que lo hagan, cómo la transforman en alertas para los – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 21 usuarios. Por ello, destacaremos de las principales aplicaciones de monitorización, los aspectos que la hacen destacar frente a otras y las carencias que presenta. Principalmente, las aplicaciones a evaluar deberán de poder facilitarnos información acerca de cualquier tipo de dispositivo que podamos tener dentro de nuestra red informática y de la mayoría de sus componentes en tiempo real: servidores físicos, virtuales, servicios de correo, antivirus, certificados web que caduquen, tráfico en bocas de routers o switches, sensores de funcionamiento, dispositivos wifi, espacio en dispositivos de almacenamiento (NAS), etc. Teniendo en cuenta la continua evolución a la que están sometidas todas las redes, se tendrá también en cuenta, que las herramientas deben tener la capacidad de adaptarse a este proceso evolutivo. Además, de mostrarlo gráficamente en un intuitivo interfaz y poseer mecanismos para avisarnos en caso de problemas. Veamos un resumen de las principales herramientas que existen en la actualidad: Pandora FMS Es de los sistemás más jóvenes y se ha convertido en una de las aplicaciones más populares y completa. Desarrollada por una empresa española: Ártica. Es una herramienta que puede estar indicada para grandes instalaciones. A su favor, podemos indicar que puede monitorizar, básicamente, cualquier tipo de sistema operativo y casi cualquier tipo de dispositivo o servicio. Esto puede realizarlo teniendo el sistema remoto instalado un cliente o a través de protocolos, sin tener que instalar nada en el destino. Puede enviar notificaciones vía email o SMS en caso de detección de problema. Necesita un gestor de base de datos, por defecto MySQL, donde almacena toda la información para ser procesada. Posee un interfaz web desarrollado en PHP5 muy ligero que, sin embargo, genera las gráficas en Flash, por lo que los navegadores deberán tener implementado este complemento para visualizarlas. Su configuración puede gestionarse desde su interfaz web, por lo que no necesitará alguien demasiado experto en sistemas – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 22 informáticos para su mantenimiento, una vez haya sido correctamente instalada y puesta en funcionamiento. En su forma de trabajo, consigue dividir en varios procesos la ejecución de sus tareas, haciendo un mejor uso de los recursos. Los cambios en su configuración, no implican un reinicio del global del sistema. Pandora FMS ha desarrollado su propio protocolo de transferencia de información, Tentacle, para intercambiar información con los clientes en los sistemas remotos, que quizás consuma más de lo deseado de recursos de tipo entrada/salida. Al ser relativamente nueva, la comunidad que la soporta no es aún muy numerosa, por lo que el mantenimiento de plugins y creación de nuevos no es demasiado dinámica. Aunque con la versión OpenSource quizás se pueda cubrir la mayoría de las necesidades de cualquier red informática, además, posee una versión bajo licencia. En la Figura 2.1 (fuente http://www.pandorafms.org), vemos su imagen comercial. Nagios También muy popular y consolidada, durante años viene siendo la herramienta de – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 23 Figura 2.1. Logo de Pandora FMS monitorización por excelencia. Reúne las principales ventajas nombradas en el caso anterior, si bien, para Nagios, se necesitará que sea el personal del departamento de sistemas el que gestione la instalación y configuración en el servidor, así como, los clientes necesarios en los dispositivos remotos. Desarrollada en Perl, integra un intérprete para los plugins desarrollados en este lenguaje, consiguiendo aumentar su rendimiento. Uno de sus puntos fuertes de es la gran flexibilidad en su configuración, así como, la creación de nuevos plugins que se encarguen de monitorizar “algo” para lo que todavía no existía ninguna opción o realizar alguna modificación a algún plugin existente para adaptarse a nuestras necesidades. Éstos pueden ser programados en diversos lenguajes como Perl, C, PHP, Python, etc. Existe una gran comunidad detrás de esta herramienta que la hace estar en continúa evolución y actualizada. Se pueden establecer jerarquías entre los dispositivos, establecer períodos diferentes de monitorización según las necesidades existentes, diferentes plantillas para controlar un mismo recurso, según sea la naturaleza del dispositivo o servicio a controlar. También permite las notificaciones por correo electrónico o SMS, diferenciando los niveles de criticidad. Como desventaja, habría que destacar su bajo nivel de gráficas de estado, probablemente debido a no soportarse bajo un motor de base de datos que almacene toda la información. Además, los cambios que realicemos en cualquier fichero de configuración, necesitarán un reinicio del servicio para que pueda ser aplicado. Su arquitectura se basa en un único proceso, que ejecuta todas las tareas programadas. Hay una variante comercial de este producto, Nagios XI, basándose en el volumen – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 24 de nodos a monitorizar. En la Figura 2.2 (fuente http://www.nagios.org), se muestra su imagen comercial. A partir de ella se han generado otras herramientas, manteniendo el núcleo de Nagios como son: Opsview o Shinkem OpenNMS Es una de las herramientas más antiguas, pero que ha seguido evolucionando hasta hoy día. Creada también para monitorizar casi todos los tipos de dispositivos de una red, al igual que en los otros casos nombrados, posee una versión totalmente gratuita alimentada por la comunidad que la mantiene y otra versión comercial. Puede lanzar aplicaciones o scripts, cuando detecta un cambio de estado en los dispositivos / servicios, incluso las notificaciones pueden ser enviadas a otras herramientas para centralizar toda la información de estado. De las funciones más importantes que añade esta aplicación, es la de ser capaz de detectar nuevos servicios y añadirlos a su configuración, aspecto muy útil para el personal responsable, ya que también le descarga de tener que añadirlo a la configuración una vez instalado. Aunque también dispone de la posibilidad de hacerlo manualmente. Genera sus propios informes y gráficas, de los datos almacenados en su base de datos en PostgreSql (único motor que soporta). Se encuentra desarrollada en Java y soporta plugins diseñados para Nagios, que actualmente es el que más plugins genera. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 25 Figura 2.2. Logo de Nagios La instalación y, sobre todo, posterior configuración para obtener un nivel de rendimiento óptimo necesita de altos niveles de conocimiento, además, su interfaz web no es demasiado intuitivo y puede no ser compatibles con todos los navegadores actuales. En la Figura 2.3 (fuente http://www.opennms.org) se muestra su imagen comercial. Zabbix Otra importante opción a tener en cuenta es Zabbix. Monitoriza las redes utilizando clientes o mediante protocolos, para poder controlar aspectos como carga del dispositivo, actividad en la red, parámetros del sistema operativo, etc. Generando informes y gráficas en su interfaz web desarrollada en PHP y JavaScript. Su servidor y agentes están desarrollados en lenguaje C. Soporta casi todos los motores de bases de datos: MySQL, PostgreSQL, SQLite, Oracle o IBM DB2. Posee un sistema de alertas para envío de notificaciones a través de email o SMS, pero además añade el uso de XMPP (antes llamado Jabber). Posee la ventaja de detectar nuevos elementos añadidos a la red y puede establecer una jerarquía entre ellos. Sin embargo, la capacidad de esta herramienta viene limitada a un número total de 1.000 nodos y al no poseer una versión Enterprise hace que no esté a la misma altura que otras herramientas de características similares. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 26 Figura 2.3. Logo de OpenNMS En la Figura 2.4 (fuente http://www.sudoers.com) se muestra su imagen comercial. Cacti Al igual que el resto de aplicaciones anteriormente referidas, recopila información de los sistemas remotos para controlarlos, en este caso, sólo a través SNMP. Además, presenta una importante gestión de las gráficas con los datos almacenados desde el momento en que empezó a monitorizar el sistema o servicio. A través de su interfaz web se realiza su configuración y permite, por ejemplo, realizar un comparativo entre todas las cargas de CPU de los servidores, o bien, comprobar el estado de espacio en disco de los servidores pertenecientes a una sede. También necesita un gestor de base de datos, MySql, para almacenar la información. Gestiona un importante sistema para definir plantillas y adecuar el interfaz gráfico a nuestras necesidades de información. No posee clientes para instalar en los servidores remotos y así, poder obtener información de otros parámetros adicionales que pudieran ser necesarios monitorizar. Tampoco posee un sistema de alertas de envío en caso de errores. En la Figura 2.5 (fuente http://datalibre.blogspot.com.es/) vemos su logotipo. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 27 Figura 2.5. Logo de Cacti Figura 2.4. Logo de Zabbix – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 34 3. INSTALACIÓN Y CONFIGURACIÓN DE NAGIOS Éste es sin duda, el capítulo principal de este proyecto. En él se detallará las siguientes etapas: proceso de instalación del servidor, instalación de Nagios, tanto en el cliente como en el servidor, así como, del envío de alertas (por email o por SMS). Se describirán los principales directorios y ficheros para realizar posteriormente su configuración y una vez finalizado, cómo podremos acceder de forma más amigable al estado de nuestra red en diferentes tipos de dispositivos. Se añadirán aplicaciones que nos proporcionen más información a cerca de lo que estaba ocurriendo hasta el momento en el que se hayan generado las alertas. Con todo ello seremos capaces de monitorizar cualquier tipo de red con Nagios de forma sencilla gracias a la flexibilidad para su configuración que proporciona. 3.1. Tipo de servidor y Sistema Operativo seleccionado Como se refirió al inicio de esta memoria, la finalidad de este TFG es la implantación de un sistema de monitorización para la red informática en el caso de TASA. Por lo que la elección del servidor y su sistema operativo, va a venir condicionado por los recursos existentes y la política del departamento informático de la empresa. Desde hace años, TASA, siguiendo directrices de la Junta de Andalucía, ha apostado por el software libre y la virtualización de sistemas. Es por ello, que teniendo ya una infraestructura creada y estable, se decida realizar la instalación de Nagios partiendo de instalaciones, sobradamente contrastadas y que nos van a proporcionar un alto rendimiento y fiabilidad. Por todo esto, se realizará sobre un Contenedor Virtual (también denominado vz) del sistema de virtualización OpenVZ. El principal argumento para justificar su instalación en este tipo de servidor, sería que todos los parámetros iniciales – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 35 asignados (espacio en disco, memoria, etc), podrán ser actualizados en “caliente”, cuando esté el servidor ya funcionando, por lo que es preferible comenzar con una configuración ajustada a nuestras necesidades, pero con la tranquilidad de que en el caso de que lo necesitemos, ejecutando un comando en el servidor físico, aumentaremos los recursos del servidor virtual de forma inmediata, sin reinicios ni paradas de servicios alguno. Además el sistema de copias (creación diaria de dumps), ya establecido sobre el servidor físico, para todos los servidores virtuales que contiene, hace que se realice también sin pérdidas de funcionamiento. Otra de las principales ventajas por la que se ha decidido el empleo de la virtualización es la movilidad. En caso de fallo del servidor físico que la alberga, si debe ser reiniciado o debemos realizar algún tipo de mantenimiento, del mismo modo que antes en “caliente”, podremos mover el contenedor a otro servidor con Openvz, y tampoco habrá parada del servidor virtual. Finalmente, debemos referir la opción de duplicar un sistema de monitorización partiendo de una copia (o dump) y actualizando su dirección IP, para evitar los conflictos de red. Algo muy útil en caso de querer tener un entorno de preproducción o desarrollo de pruebas. Del servidor físico en sí, no necesitamos conocer de forma exhausta todos sus recursos, pero sí asegurarnos que el contenedor virtual que vamos a crear, va a poder ejecutarse de forma correcta. Debemos tener en cuenta, que como se ha mencionado anteriormente, el servidor virtual puede ser desplazado de uno a otro físico sin detenerse, por lo que no existe una dependencia del servidor donde se cree. Obviamente, estaremos seguros de que todos los servidores físicos con OpenVZ, que puedan albergar los servidores virtuales, tienen recursos de sobra para ello, pero bueno, de eso ya se encargará Nagios cuando esté funcionando. Además, se comprobará que posee doble fuente de alimentación, conectadas cada una de ellas a una fase distinta del SAI principal, para evitar caídas por falta de – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 36 alimentación eléctrica. Como tampoco es objeto de este TFG el apasionante mundo de la virtualización de servidores, no quisiera desaprovechar la ocasión para recomendar acceder a http://openvz.org/ y comprobar todo el potencial de la virtualización, con sus ventajas y sus defectos. Llegado este momento, el sistema operativo seleccionado es un secreto a voces, ya que, la herramienta seleccionada es Nagios, el servidor virtual es de OpenVz y hemos apostado por Opensource. Sí, el sistema operativo será Linux y en concreto, Centos 6. Sin más preámbulos, vamos a proceder a la creación del servidor virtual para poder instalar Nagios. 3.1.1. Instalación servidor virtual A continuación, se detalla la creación de un servidor virtual dentro de un servidor físico actualmente en producción. Para ello, partiremos de una plantilla básica proporcionada por OpenVZ sobre Centos 6 y con los parámetros mínimos que debe poseer el contenedor que albergue a nuestra herramienta, Nagios. En el servidor físico, vamos a crear el nuevo servidor virtual y los comandos para su creación son relativamente sencillos: [miservidor]# vzctl create ID --ostemplate centos-6-x86_64 --config basic Con este comando se crea el servidor virtual desde la plantilla indicada (elegimos – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 37 Centos 6 de 64 bits), la configuración que va a tener inicialmente (en este caso la básica), así como, el ID que le vamos a asignar, ID (debe ser un valor numérico). Con este paso ya se habría creado el contenedor virtual y ahora deberemos configurarlo y especificar los recursos de los que podrá hacer uso del servidor físico: [miservidor]# vzctl set ID --hostname vzID.midominio.org --ipadd 192.168.10.3 --nameserver 192.168.10.20 --onboot yes --diskspace 10G:12G --cpuunits 73165 --cpulimit 0 --userpasswd root:xxxx --name NombreServidor --capability sys_time:on –save Una vez hemos creado el contenedor virtual, con este comando, le proporcionamos los parámetros de configuración básicos que deseamos, como son: hostname, dirección IP, parámetros de la CPU (con cpuunits, le indicamos la garantía de asignación de CPD que le vamos a asignar a nuestro contenedor y con cpulimit, el porcentaje máximo de CPU), servidor de nombres, espacio en disco, etc. Especificando, que en esta ocasión, se le han asignado 10GB de espacio físico en disco y que la plantilla básica de la que partimos, le asigna 3GB de memoria RAM. Estos parámetros nos indican que una herramienta tan potente como es Nagios, no necesita grandes recursos para su correcto funcionamiento. ¡Y ya está! Una vez creado nuestro servidor, podremos acceder a él una vez lo arranquemos con el siguiente comando: [miservidor]# vzctl start ID El acceso podrá realizarse a través de un nuevo terminal SSH o desde la misma línea de comando del servidor físico: [miservidor]# vzctl enter ID Este servidor, a partir de ahora, entrará a formar parte del sistema de copias diarias – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 38 (backups) para tener la seguridad de no perder información en ningún momento. 3.1.2. Configuración servidor virtual Una vez accedamos al servidor virtual, trabajaremos igual que si fuera uno físico recién instalado, y al que deberemos hacer algunos cambios, como por ejemplo, establecer una nueva contraseña para el usuario “root”, configurar zona horaria para la correcta sincronización de los sistemas e instalar un repositorio para la descargar e instalación de paquetes y realizar una actualización general del sistema. [miservidor-virtual]# passwd [miservidor-virtual]# ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime [miservidor-virtual]# rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/rpmforge-release-0.3.61.el5.rf.x86_64.rpm [miservidor-virtual]# yum update Además, deberemos eliminar algunos servicios que vienen por defecto como son el servidor de correos “sendmail” y el “iptables”, que no vamos a necesitar en este caso. Siendo también eliminados del proceso de arranque. [miservidor-virtual]# service sendmail stop [miservidor-virtual]# service iptables stop [miservidor-virtual]# chkconfig sendmail off [miservidor-virtual]# chkconfig iptables off Para finalizar, se dejan configurados el servidor web (Apache), que ya viene por defecto, y un servidor de correos (Postfix), necesarios para el funcionamiento de Nagios. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 39 [miservidor-virtual]# yum install postfix Loaded plugins: fastestmirror Determining fastest mirrors …. …. …. Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package postfix.x86_64 2:2.6.6-6.el6_5 will be installed --> Finished Dependency Resolution Dependencies Resolved =========================================================== Package Arch Version Repository Size =========================================================== Installing: postfix x86_64 2:2.6.6-6.el6_5 updates 2.0 M Transaction Summary =========================================================== Install 1 Package(s) Total download size: 2.0 M Installed size: 9.7 M Is this ok [y/N]: y Downloading Packages: postfix-2.6.6-6.el6_5.x86_64.rpm | 2.0 MB 00:04 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 40 Running Transaction Installing : 2:postfix-2.6.6-6.el6_5.x86_64 1/1 Verifying : 2:postfix-2.6.6-6.el6_5.x86_64 1/1 Installed: postfix.x86_64 2:2.6.6-6.el6_5 Complete! Una vez configurados losparámetros del servicio de correos, sólo quedará iniciarlo y añadir a la lista de procesos que el servidor debe iniciar al arrancar. [miservidor-virtual]# service postfix start [miservidor-virtual]# chkconfig postfix on 3.1.3. Instalación dispositivo envío SMS Llegado este momento, sólo faltaría una instalación complementaria para realizar los posibles envíos por SMS, en caso de notificaciones por esta vía. Para ello, se utiliza un Modem GSM con una tarjeta SIM y un software que gestione el dispositivo. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 41 Figura 3.1. Kit Modem GSM (fuente http://wiki.ispadmin.eu) Es un mecanismo muy sencillo, que consta de la instalación de un componente físico formado por los elemnetos mostrados en la Figura 3.1: Su configuración es básica y consta de dos pasos. Por una parte, una vez conectado al servidor físico que contiene a nuestro servidor virtual a través de su puerto serie, se deberá añadir a la configuración del servidor virtual con un simple comando: [miservidor]# vzctl set ID --devnodes ttyS0:rw --save lo cual creará en el fichero de configuración, ID.conf, de nuestro servidor una entrada de este tipo: …. DEVNODES="ttyS0:rwq " …. Una vez más, comentar, que este comando se ejecutaría estando el servidor virtual funcionando y sin tener que reiniciar ningún tipo de servicio. De este modo, ya estaría el dispositivo conectado al puerto serie del servidor físico, disponible para ser usado por el virtual. Ahora sólo debemos instalar el software que lo va a gestionar desde nuestro servidor virtual, en este caso, ya que el tipo de software que gestiona un equipo GSM es muy básico, se ha optado por GAMMU, una vez más, elegimos una aplicación tipo OpenSource y siendo de los más populares y empleado para este fin: [miservidor]# yum install gammu.x86_64 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: sunsite.rediris.es * epel: ftp.pbone.net – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 42 * epel-debuginfo: ftp.pbone.net * epel-source: ftp.pbone.net * extras: sunsite.rediris.es * rpmforge: apt.sw.be * updates: sunsite.rediris.es Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package gammu.x86_64 0:1.11.0-1.el6.rf will be installed --> Processing Dependency: libbluetooth.so.3()(64bit) for package: gammu1.11.0-1.el6.rf.x86_64 --> Running transaction check ---> Package bluez-libs.x86_64 0:4.66-1.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved =========================================================== Package Arch Version Repository Size =========================================================== Installing: gammu x86_64 1.11.0-1.el6.rf rpmforge 1.3 M Installing for dependencies: bluez-libs x86_64 4.66-1.el6 base 75 k Transaction Summary =========================================================== Install 2 Package(s) – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 43 gd-devel x86_64 2.0.35-11.el6 base 78 k mod_ssl x86_64 1:2.2.15-30.el6.centos updates 91 k Updating: glibc x86_64 2.12-1.132.el6_5.2 updates 3.8 M glibc-common x86_64 2.12-1.132.el6_5.2 updates 14 M httpd x86_64 2.2.15-30.el6.centos updates 821 k net-snmp x86_64 1:5.5-49.el6_5.1 updates 306 k net-snmp-utils x86_64 1:5.5-49.el6_5.1 updates 174 k openssl x86_64 1.0.1e-16.el6_5.14 updates 1.5 M openssl-devel x86_64 1.0.1e-16.el6_5.14 updates 1.2 M Updating for dependencies: glibc i686 2.12-1.132.el6_5.2 updates 4.3 M glibc-devel x86_64 2.12-1.132.el6_5.2 updates 978 k glibc-headers x86_64 2.12-1.132.el6_5.2 updates 608 k httpd-tools x86_64 2.2.15-30.el6.centos updates 73 k net-snmp-libs x86_64 1:5.5-49.el6_5.1 updates 1.5 M nscd x86_64 2.12-1.132.el6_5.2 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 50 updates 219 k Transaction Summary =========================================================== Install 2 Package(s) Upgrade 13 Package(s) Comprobamos que en la instalación a través de yum se resuelven también las dependencias. Los ficheros de configuración de Nagios se encuentran almacenados en varios directorios y todos tienen extensión “.cfg” (ficheros de texto plano). Tras la instalación la estructura del directorio “/etc/nagios”, debería contener estos archivos: [miservidor-virtual]# ls -lR .: total 72 -rw-rw-r-- 1 root root 11658 Aug 31 2013 cgi.cfg drwxr-x--- 2 root nagios 4096 Aug 31 2013 conf.d -rw-rw-r-- 1 root root 44533 Aug 31 2013 nagios.cfg drwxr-x--- 2 root nagios 4096 Aug 29 17:22 objects -rw-r----- 1 root apache 27 Jun 16 13:24 passwd drwxr-x--- 2 root nagios 4096 Jun 16 12:54 private ./conf.d: total 0 ./objects: total 48 -rw-rw-r-- 1 root root 7704 Aug 31 2013 commands.cfg -rw-rw-r-- 1 root root 2166 Aug 31 2013 contacts.cfg – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 51 -rw-rw-r-- 1 root root 5629 Jun 16 13:31 localhost.cfg -rw-rw-r-- 1 root root 3124 Aug 31 2013 printer.cfg -rw-rw-r-- 1 root root 3293 Aug 31 2013 switch.cfg -rw-rw-r-- 1 root root 11158 Aug 31 2013 templates.cfg -rw-rw-r-- 1 root root 3208 Aug 31 2013 timeperiods.cfg -rw-rw-r-- 1 root root 4019 Aug 31 2013 windows.cfg ./private: total 4 -rw-r----- 1 root nagios 1340 Aug 31 2013 resource.cfg Donde los principales directorios y archivos son: ./nagios cgi.cfg: En este fichero se indica a los cgi's dónde deben encontrar los principales datos de la configuración de Nagios para su entorno web, como es la ubicación de ficheros HTML, usuarios autorizados para acceder a ciertos apartados de configuración vía web, tipos de gráficos, etc. nagios.cfg: Es el fichero más importante en la configuración de Nagios. En él se indicarán los ficheros que contienen la información de los objetos que debe monitorizar, dónde y cómo almacenar la información, cómo gestionar los ficheros de logs, así como, parámetros de configuración de la aplicación en sí. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 52 ./nagios/private resource.cfg: En él se indicarán los directorios donde se almacenan los recursos que va a utilizar Nagios durante su ejecución, por ejemplo, dónde se encuentran los plugins o los eventos que debe lanzar para solucionar algún problema. Se identificarán como “$USERn$”. ./nagios/objects commands.cfg: Es el fichero que reúne la forma en la que funcionarán los plugins. Si creáramos un plugin nuevo, deberíamos de declarar aquí cómo debería usarse: parámetros, ubicación, argumentos que necesita recibir, etc. También se indicará cómo configurar los mensajes de envío por SMS o email. Los demás vienen por defecto y su nombre hace referencia a las definiciones que contienen. El nombre que se les proporciona a los ficheros de configuración debe ser el mismo al que se le haga referencia en el fichero “nagios.cfg”. En este TFG, los nombraremos de forma básica e intuitivos para poder comprender mejor la relación entre ellos: localhost.cfg: Contiene la información de los parámetros del propio servidor de Nagios que deseamos sean monitorizados. Es el único host con servicios predefinido. hosts.cfg: Definición de los hosts, servidores o dispositivos que se van a monitorizar services.cfg: – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 53 Definición de los servicios que se desea monitorizar contacts.cfg: Definición de los contactos templates.cfg: Plantillas para la definición “base” o “tipo” de hosts/servicios timeperiods.cfg Definición de intervalos de tiempo para monitorizar objetos printer.cfg: Descripción a modo de ejemplo de definición de impresora a ser monitorizada switch.cfg: Al igual que para las impresoras, un ejemplo para los dispositivos tipo switch donde configurar todos los dispositivos de la electrónica de red Además de estos ficheros, Nagios admite una personalización de nuestra configuración de forma sencilla. Sólo hay que crear nuestros propios archivos “*.cfg” con nombres intuitivos que reúnan los objetos que queremos monitorizar según sean de naturaleza similar o porque se encuentren todos reunidos en una ubicación. Una vez creado, sólo habrá que indicarle a “nagios.cfg” el nombre y su ubicación. Algunos ejemplos pueden ser: virtual-linux.cfg: Servidores virtuales con sistema operativo Linux sede-almeria.cfg: Objetos a monitorizar en la sede de Almería sensores.cfg: Definición de todos los sensores: consumo eléctrico, temperatura, etc – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 54 Adicionalmente, y por una cuestión meramente organizativa, se pueden crear agrupaciones con los hosts, servicios y contactos, de tal forma que añadiríamos los siguientes ficheros de configuración, cuyo contenido veremos en este apartado, más adelante y se comprenderá mejor su finalidad: hostgroups.cfg: Definición de grupos de hosts que se formarán con los hosts definidos en el fichero anterior servicegroups.cfg Definición de los grupos de servicios contactgroups.cfg: Definición de los grupos de contactos Otros ficheros que suelen usarse en la comunidad Nagios son: escalations.cfg: se trata de establecer una escala para los avisos. Si una alerta sobre un servidor o servicio no es resuelta tras haber enviado un número de alertas, se empezarán a enviar a otros responsables, ya sean jefes o personal más cualificado. miscommands.cfg: es el fichero donde se suele configurar la información de las notificaciones por email o SMS. También puede definirse dentro de “commands.cfg”. dependencies.cfg: se pueden establecer relaciones entre servicios o hosts, que generen notificaciones u otros chequeos dependiendo del estado de los mismos. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 55 .htaccess / .htpasswd.users: se utiliza para limitar el acceso de usuarios al interfaz web. Para mejorar la seguridad, en el caso de implementación de TASA, se realizará a través de LDAP. Por lo que no se hará uso de estos ficheros. Indicar que la distribución de las definiciones en distintos ficheros es opcional y se hace por jerarquizar la configuración, pero podemos simplificar la configuración y reunir en un sólo fichero el contenido de varios, siempre que respetemos la sencilla sintaxis de Nagios. Por ejemplo, en un sólo fichero hosts.cfg, podemos incluir también la configuración de los hostsgroups.cfg y hacer lo mismo para los servicios, etc. La flexibilidad y simplicidad para la configuración que presenta esta herramienta es uno de sus mayores valores. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 56 Figura 3.2. Interfaz gráfico de Nagios (Fuente: http://es.wikipedia.org) Durante todo el proceso de instalación, Nagios dejará en /var/log/nagios/nagios.log, información de problemas que pudieran surgir para poder resolverlos. Si todo ha ido bien hasta ahora, podríamos acceder al interfaz gráfico de nuestro Nagios como aparece en la Figura 3.2, aunque no hayamos definido nada aún. 3.2.2. Nagios en el cliente En este TFG, detallaremos la instalación de dos tipos de clientes según el sistema operativo, ya sea para Linux o para Windows. Si algún dispositivo no tiene uno de estos sistemas operativos, se podrán utilizar otros protocolos para su monitorización como SNMP. Adicionalmente, hay que tener en cuenta que Nagios no vigila sólo los componentes que pertenezcan a su rango de direccionamiento IP. Para ello, deberá configurarse la visibilidad entre el servidor principal de Nagios y el resto de todos los componentes. En caso de existir un cortafuegos, deberían definirse las reglas necesarias para permitir al servidor principal llegar al resto de objetos. Por lo que una vez instalado los clientes, se deberá comprobar la visibilidad entre servidor-cliente. 3.2.2.1. Cliente Nagios para Linux El cliente Nagios para Linux es NRPE (Nagios Remote Plugin Executor). Es una aplicación que gestiona las peticiones que Nagios realiza sobre el estado de los parámetros que se han decidido monitorizar en cada sistema. En la Figura 3.3, se muestra cómo Nagios realiza una petición sobre un equipo Linux con el cliente instalado. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 57 Para ello deberemos acceder al servidor donde queremos instalar el cliente y realizar los siguientes pasos: primero configurando los ficheros que permitirán la interacción con Nagios del propio sistema y después el del propio cliente NRPE para indicarle quién y qué va a monitorizarle: Instalación del cliente y los plugins * yum install nagios-nrpe nagios-plugins Cambiar los permisos y propietario para el fichero de configuración * chown nagios:nagios /etc/nagios/*cfg Editar /etc/hosts.allow para permitir que el servidor donde hemos instalado Nagios, pueda tener acceso * vim /etc/hosts.allow y añadir 192.168.10.3 Editar /etc/services para que el puerto del servicio Nagios, 5666, esté – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 58 Figura 3.3. Interacción de Nagios con el cliente NRPE de sistemas Linux (Fuente: http://tecadmin.net) preparado para atender peticiones de este tipo * vim /etc/services y añadir el puerto: "nrpe 5666/tcp # Nrpe Nagios" Ahora, sí que se debe configurar el cliente de Nagios, NRPE. Para ello, tras editar su principal fichero de configuración, nrpe.cfg, deberemos darle permisos a la dirección IP del serviodor, para que pueda realizar peticiones a través del puerto indicado anteriormente, 5666. (Podremos añadir tantos servidores Nagios como deseemos que quieran monitorizar este sistema, separando cada dirección IP por comas) * vim /etc/nagios/nrpe.cfg y modificar "allowed_hosts=192.168.10.3" En este mismo fichero, “nrpe.cfg”, casi al final, se encuentran los servicios que vamos a permitir se “consulten” por parte del servidor principal de Nagios. Por ejemplo, en caso de la carga del sistema, deberíamos añadir una línea parecida a esta: * command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,7 -c 30,25,20 que describiremos más adelante, junto con el resto de funcionamiento de los principales plugins, durante la configuración del sistema completo. Ya solo nos queda arrancar el servicio y añadirlo al arranque del sistema para cuando sea reiniciado. * service nrpe start * chkconfig --level 345 nrpe on – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 59 host_name: nombre con el que se hará referencia al objeto, dentro de los ficheros de configuración de Nagios alias: nombre del host que visualizará el interfaz gráfico, al cual se le puede asignar una etiqueta más descriptiva, si no se indica, aparecerá el nombre asignado en “host_name” address: es la dirección IP a la que Nagios debe acceder para monitorizar este objeto icon_image: icono que deseamos se muestre al presentar el host en el interfaz web statusmap_image: icono para identificarlo en el mapa de estado de Nagios parents: en el caso de que así sea, indicamos de qué otro/s servidor/es depende. Básicamente, se empleará para establecer una jerarquía, que será muy útil para monitorizar y realizar la representación de los mapas del sistema. En algunos casos, se puede especificar más de un valor, según la relación existente entre ellos notes_url: lo explicaremos más adelante, pero a través de este parámetro, proporcionamos un enlace a otra url que contiene información ampliada de este host. 3.3.2. services.cfg ¿Qué tipos de servicios puede monitorizar Nagios? Pues realmente casi cualquiera que deseemos: una página web, un servidor de nombres, un servidor de bases de datos, el tamaño de un sistema de archivos, si un puerto de un switch tiene tráfico, si un certificado web está a punto de caducar, número de usuarios conectados a un – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 66 servidor, etc y lo mejor de esta herramienta es, que si no existe el plugin al que el servicio pueda invocar para conocer el estado, siempre nos quedará la opción de desarrollarlo nosotros mismos y contribuir a la comunidad de Nagios, por si puede necesitarlo alguien con nuestras mismas necesidades. La configuración de los servicios tampoco es demasiado complicada, pero hay que diferenciar entre varios conceptos: definición del servicio genérico, definición del comando que ejecuta el plugin y los datos de nuestro servicio a monitorizar según lo anteriormente establecido. Una vez más, todo esto se ve más claro con un ejemplo. Como comentamos en el caso de los hosts, el servicio más sencillo a monitorizar será la respuesta al PING de un host, pues bien, para ello deberemos configurar en este fichero: define service{ use generic-service name ServicioPing service_description DescServicio check_command check_ping!500.0,30%!800.0,60% } Al igual que ocurría en el caso de definición de los hosts, para los servicios también heredamos la mayoría de los valores de las plantillas definidas en “templates.cfg”, indicando aquí, los valores concretos para este servicio, como son: use: plantilla de la que partimos (se detallará más adelante) name: nombre del servicio service_description: etiqueta con la que se visualizará el servicio en la web. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 67 check_command: los datos de qué plugin queremos utilizar para este servicio y sus valores de parametrización. En este caso, este servicio monitoriza el PING, haciendo uso del plugin “check_ping” al que se le pasan los parámetros tras el signo de exclamación. Además, indicaremos dentro de este mismo fichero, qué host es el que queremos monitorice el servicio de PING: define service{ use ServicioPing host_name NombreHost1, NombreHost2 } Para que esto funcione, comprobaremos que en el fichero “commands.cfg” aparece la entrada para este pluging, que recibe los valores que acabamos de definir en nuestro servicio: # 'check_ping' command definition define command{ command_name check_ping command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ } command_name: es el nombre del servicio, que debe coincidir con el usado en nuestra definición del servicio en el parámetro “check_command” command_line: es el que se encarga de ejecutar el comando en sí. Busca el script “check_ping” en el directorio que habremos configurado como “$USER1$”. Lo ejecutará con los parámetros indicados, -w, para el umbral de aviso o Warning, $ARG1$, y -c para el crítico o Critical, $ARG2$, y para el host especificado, – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 68 $HOSTADDRESS$, es la dirección IP de NombreHost1 de nuestro ejemplo. Hay que tener en cuenta, tanto para este plugin, como para cualquier otro, que los umbrales pueden ser totalmente distintos dependiendo del sistema en el que lo ejecutemos y según el interés o criticidad que tenga. Este es otro factor que indica la versatilidad y flexibilidad de Nagios. Este fichero “commands.cfg”, trae por defecto la definición de los parámetros y forma de invocar los plugins básicos de Nagios. En caso de añadir nosotros un nuevo plugin, deberemos, además de ubicarlo en el directorio correcto, definirlo en este fichero para que pueda atender las llamadas realizadas desde ficheros como “services.cfg”. En el caso de la definición de servicios, debemos hacer una descripción más detallada de la definición de servicios para el caso de que interactúen con los clientes NRPE y NsClient+, anteriormente descritos. La definición del servicio es básicamente la misma, mostramos un ejemplo y a continuación lo describiremos. Vamos a ver cómo se definirían los servicios que comprueban la carga de un sistema para el caso de NRPE (cliente Linux): define service{ use generic-service host_name NombreHost1 service_description Carga Actual check_command check_nrpe!check_carga } En este caso, con el plugin check_nrpe, Nagios solicita información al servidor NombreHost1. Éste tiene el cliente NRPE instalado y en su fichero de configuración, “nrpe.cfg”, hay una entrada para comprobar la carga, “check_carga” con sus correspondientes parámetros, como vimos antes: – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 69 …........ command[check_carga]=/usr/lib64/nagios/plugins/check_load -w 15,10,7 -c 30,25,20 ….... Como vimos antes en el caso del servicio de PING, la opción “-w” indicará el umbral de aviso para “Warning” y la “-c” para el caso “Critical”. Y para el caso de NsClient+ (cliente Windows): define service{ use generic-service host_name NombreHost1, NombreHost2 service_description CPU Load check_command check_nt!CPULOAD!-l 5,80,90 } la sintaxis es igual, pero en este caso se le proporciona los valores en la misma consulta, sin tener que configurar nada en el cliente, como ocurría anteriormente. Para terminar la configuración de servicios, deberemos comentar la definición de lanzamiento de eventos que puedan realizar una acción adicional una vez se produzca un cambio de estado: define service{ …..... event_handler reinicia_httpd!$SERVICESTATE$!$SERVICEATTEMPT$ event_handler_enabled 1 …....... } – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 70 Con ello conseguiríamos ejecutar el script “reinicia_httpd” cuando haya un error. 3.3.3. hostgroups.cfg Otros ficheros de configuración son los que agrupan los hosts o servicios, como son “hostsgroups.cfg” y “servicegroups.cfg”. Este tipo de agrupamiento de servidores o servicios, nos ayudará en la simplificación de las configuraciones, y además, en el interfaz gráfico aparecerán agrupados según los definamos, con lo que conseguiremos un mejor entendimiento de nuestra organización y mejor visualización de las alertas. Para el caso de servidores, las definiciones en “hostgroups.cfg” serían algo así: define hostgroup{ hostgroup_name NombreGrupoHost alias Grupo1 Servidores members NombreHost1, NombreHost2 } Con esta agrupación, partir de este momento, podemos monitorizar el mismo servicio para todo un grupo de servidores de forma sencilla, con definiciones de este tipo: define service{ use ServicioPing hostgroup_name NombreGrupoHosts1, NombreGrupoHost2 } Con esta definición, controlamos el servicio del PING de todos los servidores – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 71 agrupados, no sólo en NombreGrupoHosts1, sino también en otro grupo denominado NombreGrupoHosts2. Pudiendo añadir todos los grupos que queramos separando los nombres por comas. 3.3.4 servicegroups.cfg En este caso, se define un grupo de servicio, siguiendo con nuestro ejemplo, para el servicio de PING, la configuración sería así: define servicegroup { servicegroup_name GrupoServicioPing members NombreHost1,PING, NombreHost2,PING } 3.3.5. contacts.cfg Llegado este momento, hemos configurado nuestro Nagios con los servidores, servicios y plugins. Falta la otra parte, no menos importante, para finalizar la configuración. Ahora debemos definir quienes son los responsables, o también llamados “contactos”, a los que se debe avisar en caso de que se produzca alguna alerta y definir en la vía en la que se debe hacer la notificación. Dentro de este fichero se configurarán uno a uno todos los contactos (responsables) a los que se les deban enviar un aviso cuando se produzca una alerta en el sistema de monitorización. La declaración de cada uno de ellos debe ser así: define contact { – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 72 contact_name nagiosadmin1 use generic-contact alias Administrador NAGIOS email [email protected] pager +34666123456 } contact_name: es el nombre del contacto use: indica la plantilla de la que hereda el resto de los parámetros alias: etiqueta con la que aparecerá en el interfaz gráfico email: dirección de correo electrónico a la que se le enviarán las notificaciones pager: número de móvil al que enviar los SMS de alerta. 3.3.6. contactgroups.cfg Siguiendo con la simplificación a la hora de configurar Nagios, con los contactos volveríamos a agruparlos en la medida de lo posible para hacer referencia a grupos de contactos que deban recibir las notificaciones. La declaración de los grupos sería de esta forma: define contactgroup{ contactgroup_name nagiosadmin alias Administradores NAGIOS members nagiosadmin1, nagiosadmin2 } – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 73 contactgroup_name: es el nombre del grupo dentro de nuestra configuración alias: como en ocasiones anteriores, es la etiqueta con la que se visualizará en el entorno web members: son todos los “contact_name” definidos anteriormente, que deseemos agrupar en este caso. 3.3.7. timeperiods.cfg Hasta el momento, hemos definido todo lo que queremos monitorizar, de qué forma y a quién debemos hacer llegar los avisos por alertas. Bueno, pues ahora debemos establecer los períodos de tiempo en los que deseamos que se realicen. Para ello, existe este fichero, donde se definen de la siguiente forma: define timeperiod{ timeperiod_name 24x7 alias 24 Horas al Día, 7 Días a la semana sunday 00:00-24:00 monday 00:00-24:00 tuesday 00:00-24:00 wednesday 00:00-24:00 thursday 00:00-24:00 friday 00:00-24:00 saturday 00:00-24:00 } define timeperiod{ timeperiod_name smshoras – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 74 alias SMS Horas sunday 08:00-24:00 monday 08:00-24:00 tuesday 08:00-24:00 wednesday 08:00-24:00 thursday 08:00-24:00 friday 08:00-24:00 saturday 08:00-24:00 } timeperiod_name: nombre que se le proporciona a este período de tiempo alias: nombre con el que se visualiza en el entorno gráficos monday – sunday: por cada día de la semana, se especifica un intervalo de horas. De 00:00 a 24:00, si queremos todo el día, o por ejemplo, para el envío de SMS, de 08:00 a 24:00. Dependiendo de la criticidad del sistema a monitorizar se podrá ampliar o reducir el intervalo de tiempo. 3.3.8. templates.cfg Nagios presenta un gran número de parámetros para la configuración de los objetos a monitorizar. Para la definición de los mismos, lo más recomendable es crear una plantilla, con todos los parámetros comunes a un gran número de objetos / servicios / contactos / períodos de tiempo y después, en los ficheros como los que acabamos de describir, (hosts.cfg, services.cfg, contacts.cfg,..) crear una entrada para cada uno de ellos, con sus valores propios, indicando que el resto de valores, los tomará de la plantilla indicada. Dependiendo del grupo de elementos a monitorizar se definirán valores distintos para cada opción. Así, para los dispositivos más sencillos y poco críticos, podremos establecer que – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 75 Listado de cada dispositivo y de cada servicio Agrupados según hayamos definido en hostgroups y servicegroups, respectivamente Ver un mapa de estado en el que se posicionen todos los objetos y la jerarquía que hemos establecidos entre ellos Listado sólo de los hosts y servicios que tienen en este momento algún problema (su estado es diferente de “OK”) Cortes que se hayan producido en la red, caídas de líneas de datos Comentarios que se van añadiendo para hosts y services a tener en cuenta antes/durante/después de las incidencias Tiempos en los que por algún motivo ha estado sin monitorizarse, por un reinicio del sistema, porque se va a realizar mantenimiento en el CPD, etc, se debe documentar para tener en cuenta al analizar los datos de estado de los hosts y servicios. Los superusuarios también podrán cambiar parámetros de la configuración desde la “Información de Procesos”, donde se podrá reiniciar el servicio de Nagios, apagarlo, deshabilitar todas las notificaciones, detener todos los chequeos, etc. Tener información acerca del rendimiento que tiene actualmente Comprobar el estado de la “Cola de Programación”, orden en el que se – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 82 van a realizar los próximos chequeos. Reportes: En este apartado, podremos generar informes del estado de toda la red según nuestras necesidades de información. Proporciona multitud de combinaciones para seleccionar los objetos, el período y demás parámetros que queremos recopilar y crear los resúmenes que necesitemos. Además, podemos ver las últimas notificaciones enviadas y un “Visor de Sucesos”, con los últimos cambios de estado que se han producido en los componentes de la red. Configuración: Sólo disponible para el personal responsable de Nagios y de la red, mostrará toda la configuración que hayamos plasmado en los ficheros de configuración, al igual que antes, nos proporciona formularios para agrupar la información de la que realmente queremos comprobar la información. A continuación, se muestran algunas capturas de pantalla que acabamos de describir (Figuras 3.7 y 3.8): – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 83 Figura 3.7. Estado de los servicios definidos para localhost En estos ejemplos, podemos ya intuir el potencial que va a tener Nagios una vez configuremos nuestra red. Para un solo servidor, podemos ver toda la información de su estado, configuración e incluso realizar acciones directamente sobre él desde el interfaz web, como por ejemplo, silenciar las notificaciones, porque es un error conocido y ya estamos en vías de solucionar el problema. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 84 Figura 3.8. Estado de "localhost" y posibles acciones 3.5. Otras opciones para comprobar estados y alertas Como ya se ha comentado a lo largo de este TFG, la forma de interactuar con Nagios será vía Web en la que podremos comprobar el estado de todos nuestros objetos monitorizados y recibiendo avisos de alertas vía email o SMS. Pues bien, además existen otras opciones muy útiles como son los complementos gráficos para los navegadores web y las aplicaciones para móviles o tabletas. Suelen mostrar un resumen del estado global de incidencias en la posición de la pantalla que le indiquemos (por ejemplo, en la barra de estado). Éstas interactúan mostrando el cambio de estado de algún dispositivo en ventanas o pop-ups, o también, emitiendo sonidos por si no hay nadie frente al monitor en ese momento. 3.5.1. Complementos para navegadores web También conocidos como “addons”, se instalan en los navegadores web que usamos habitualmente. Tras ser configurado con los datos de nuestro servidor de monitorización, podremos ser avisados del estado de todo nuestro sistema, de la forma que indiquemos y nos proporcione este complemento: señales visuales en la barra de estado, aparición de nuevas ventanas mostrando la notificación, emisión de algún tipo de sonido, etc. El complemento más empleado hoy día por su simplicidad para ser configurado y eficiencia es “Nagios CheCker”. En esta capturas a modo de ejemplo, se muestran algunas configuraciones e iconos de estado de Nagios, para Chrome (Figura 3.9) y Firefox Mozilla (Figuras 3.10). – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 85 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 86 Figura 3.10. Nagios Checker para Mozilla Firefox Figura 3.9. Nagios Checker para Google Chrome 3.5.2. Aplicaciones móviles Actualmente existen numerosas aplicaciones para instalar en nuestros teléfonos móviles inteligentes o en tablets. Dependiendo del servicio e información que nos proporcionen, serán gratuitas o de pago. Al igual que en el caso de los complementos en navegadores, tras proporcionarle los datos de configuración para poder acceder a nuestro sistema de monitorización, en tiempo real, tendremos toda la información de nuestro sistemas y podremos establecer nuevos sistemas de notificaciones como sonidos. A continuación, se enumeran las más usuales, diferenciándose por el sistema operativo del móvil en el que vayan a ser instaladas y configuradas: Android o IOS. Android Existen diversas opciones, pero aquí mencionaremos las dos más usuales, que pueden ser descargadas desde https://play.google.com/store, para terminales con este SO. Anag. Figura 3.11. Donde se indican datos generales del estado de la red y de las alertas producidas por cambios de estado Nagios+Plus. Figura 3.12. Muestra en qué estado se encuentran los dispositivos y podemos ampliar la información del que deseemos, incluso poner en silencio las notificaciones para este dispositivo / servicio. IOS Para el caso de sistemas Apple, deberemos buscar en el AppleStore aplicaciones como las siguientes. Estos ejemplos son de instalación gratuita inicialmente. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 87 Nagios-Mobility. Figuras 3.13, donde resumidamente, se muestra el estado de todos los elementos monitorizados, inidicando cuántos están bien y cuántos tienen algún tipo de alerta en este momento, tanto de servidores como de servicios. Adicionalmente, se puede consultar cada uno de ellos para ampliar la información. TouchMon for Nagios Lite Figuras 3.14, donde nos muestra varios de los servicios controlados – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 88 Figura 3.12. Ejemplo pantalla Nagios+Plus Figura 3.11. Ejemplo pantalla Anag y si con estos tipos de alertas no tenemos suficiente, siempre podremos darnos un paseo por la página http://zeldor.biz/2011/04/nagiosicinga-traffic-light/, donde nos indican cómo fabricar y configurar un auténtico semáforo que nos alertará siempre de los cambios de estado de los dispositivos que deseemos. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 89 Figura 3.14. Ejemplo pantalla TouchMon Figura 3.13. Ejemplo pantalla Nagios-Mobility 3.6. Aplicaciones adicionales Como vimos en apartados anteriores, existe una gran cantidad de software disponible para el control de nuestras redes informáticas, con sus ventajas e inconvenientes, creemos conveniente detallar cómo algunas de estas herramientas pueden adicionalmente cumplimentar la labor de Nagios y aumentar el potencial de nuestra instalación de monitorización. Nos pararemos a comentar en concreto dos de ellas: cacti y mrtg. 3.6.1. Cacti Nagios + Cacti = monitoring, alerting, and historical performance happiness (Fuente: http://www.linux.com/) Cacti, como vimos durante el comparativo de herramientas de monitorización, también es por sí sola una aplicación encargada de vigilar sistemas informáticos. Ya mencionamos que carece de algunas características que considerábamos esenciales para nuestro objetivo, sin embargo, sí que debemos tener en cuenta la completa gestión de recolección de datos y graficado que aporta respecto a los dispositivos que monitoriza. Parece entonces recomendable, que para los servidores más críticos podamos tener más información y poseer un gran histórico de la evolución de los mismos, para poder deducir qué ocurría antes de un fallo o el comportamiento irregular de algún parámetro, que por no llegar a los parámetros de umbrales de alertas, Nagios no nos va a alertar. Además de todo esto, el propio Nagios posee un plugin que puede invocar los datos que Cacti tiene de algún dispositivo en concreto, por lo que habremos conseguido reunir una gran cantidad de información complementaria y extremadamente importante para analizar los problemas que hayan surgido y encontrar su solución de – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 90 forma más eficiente. No nos pararemos a explicar la instalación de la herramienta ni su configuración. Pero sí quisiéramos comentar, que establecer la relación entre un dispositivo controlado por Nagios y Cacti es bastante sencilla. Partiendo de que ambas herramientas ya están funcionando correctamente, y que ambas vigilan un mismo dispositivo (misma dirección IP), bastaría con añadir una nueva línea a la definición del host dentro de Nagios, (durante la anterior descripción del fichero “hosts.cfg”, dejamos pendiente la definición de la línea correspondiente a “notes_url”): define host { use generic-host host_name NombreHost alias AliasHost address 10.168.10.5 icon_image base/linux40.gif statusmap_image base/linux40.png parents NombreNodoPadre notes_url $USER1$/cacti/cactiplug.php?ip=$HOSTADDRESS } notes_url: este parámetro se emplea para enlazar el host con otras aplicaciones o urls, generalmente para mostrar información amplaida. En este caso invocaría la representación gráfica de sus datos correspondientes en Cacti, a través del plugin, en este caso desarrollado en “php”. En la siguiente captura de pantalla, Figura 3.15, se puede apreciar cómo se accedería a esta información, desde Nagios, donde debe aparecer un enlace en forma de icono (por lo general el de Cacti, por ser lo más intuitivo) que indicará que es un dispositivo que tiene información ampliada en dentro de esta otra aplicación: – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 91 Posee un Departamento informático bien estructurado y consolidado a lo largo del tiempo, con personal especializado en distintas áreas como puede ser la microinformática, asistencia a los usuarios, aplicaciones, desarrollos web y, por último, sistemas informáticos y redes. Se puede ampliar la información sobre TASA en http://www.andalucia.org, portal turístico de la marca Andalucía y en http://www.turismoandaluz.com, extranet de la empresa con toda su información. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 98 4.2. Monitorización red informática TASA Como se puede intuir, al igual que le ocurre a la mayoría de las redes informáticas de las empresas hoy día, este tipo de infraestructuras sufren cambios casi a diario y este dinamismo puede llevar a una situación de caos si no tiene “detrás” un buen sistema de monitorización siempre actualizado y bien documentado que descargue a los responsables, teniendo la seguridad de que todo está funcionando como se ha diseñado. Esta evolución puede venir tanto por cambios de ubicación, como por evolución en los equipos o sustitución de los mismos por otros más actuales y de mayor capacidad, aparición de nuevos dispositivos o servicios, etc. Por ello, llegado el momento, se decidió llevar a cabo este trabajo de implementación de una herramienta de monitorización para toda la red informática, que acabado siendo este Trabajo Fin de Grado. Por una parte, de forma consensuada, el departamento de sistemas analizó de forma exhaustiva todos los componentes que formaban parte de la red, agrupando sus componentes por sedes y decidiendo los dispositivos y servicios indicados para ser controlados por la monitorización, así como, la clasificación de nivel de criticidad de los mismos, contactos finales para recibir notificaciones, etc. En el momento de la recogida de datos, están siendo monitorizados alrededor de 200 dispositivos y casi 800 servicios. Estos dispositivos pertenecen a distintas redes con direccionamientos IP muy diferentes, por lo que en el cortafuegos se ha debido habilitar las visibilidades entre el servidor de Nagios y cada una de ellas: electrónica de red (switches y routers), sistemas de alimentación ininterrumpida (SAI), sensores ambientales o de consumo (humedad, temperatura, consumo eléctrico), redes de servidores, redes de usuarios, redes de dispositivos wifi para usuarios externos e internos, etc. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 99 En un principio, se empezó por monitorizar todos los servidores del principal CPD con sus correspondientes servicios. Una vez comprobada la eficacia del sistema y teniendo una configuración estable, se extrapoló al resto de sedes, aunque siendo estas menos críticas, se optó porque los umbrales de alerta y parámetros de solicitud de información del estado de los elementos, se adecuaran a la importancia de cada uno de ellos. Los dispositivos monitorizados se agruparon por nivel de importancia, similitud en su función o bien por sede, podemos ver en la siguiente Figura 4.1 una parte de ellos: En esta imagen podemos ver la información distribuida en tablas donde se han agrupado los servidores en grupos (información que previamente hemos definido en el fichero “hostgroups,cfg”) de switches/routers, servidores principales Windows o Linux, virtuales OpenVZ o KVM, sensores de consumo, etc. lo cual nos proporciona – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 100 Figura 4.1. Algunos grupos de host creados para la red de TASA una visión más cómoda de todos los dispositivos. Aunque se represente de forma agrupada, en todo momento, pulsando sobre el servidor deseado, podremos acceder a toda su información o, a través de la columna “Actions”, situarlo en el mapa de la red, ir a sus datos recogidos en Cacti (si los tiene), realizar llamada al complemento PNP4Nagios y ampliar más la información almacenada. Sin embargo, la forma más intuitiva de representar la red completa de TASA, se muestra a continuación, en la siguiente Figura 4.2, donde podemos ver el mapa con el que Nagios nos la representa: Representación que nos será muy útil en caso de caída múltiple de servicios para ir viendo en cada momento el estado de todas las sedes o bien, para situar un – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 101 Figura 4.2. Mapa de Nagios para la red de TASA dispositivo dentro de la jerarquía que hayamos definido. Para completar esta información, sobre todo lo que está ocurriendo en la red, como comentamos durante su instalación, Nagios nos proporciona varias opciones de creación de reportes y gráficas que nos lo muestran de forma personalizada seleccionando el host/servicio, intervalos de tiempo, estados por los que ha pasado, etc. Esta información se amplía con capturas de pantalla en el apartado que veremos más adelante sobre capturas de pantallas adicionales de la aplicación. En los siguientes apartados veremos algunos de los elementos “tipo”, que son monitorizados a través de Nagios, dependiendo del tipo de dispositivo y de su criticidad, para la red de TASA. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 102 4.3. Servidores / Servicios monitorizados en TASA En este apartado veremos cómo se monitorizan algunos los elementos de TASA. Servidor OpenVZ Como comentábamos, no todos los servidores son “vigilados” de la misma forma, así los servicios a tener en cuenta en cada uno de ellos pueden ser diferentes. Para este caso, según vemos en la Figura 4.3, por ser un servidor físico para dar servicio a virtualización OpenVZ, se monitorizan servicios a través del cliente NRPE como: Amanda-OK: si se ha realizado el proceso de copias de seguridad del sistema correctamente. Se comprueba que existe un fichero en el directorio indicado con una antigüedad inferior a 24 horas. Carga Actual: se comprueba el estado de la carga del sistema Dumps-OK: indica que se han realizado correctamente las copias (o dumps) de los – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 103 Figura 4.3. Monitorización Servidor OpenVZ contenedores virtuales que alberga en ese momento Espacio en Boot / Raíz: el espacio en la partición de arranque o raíz del sistema es correcta. Espacio_en_vz: El espacio destinado a los contenedores virtuales es correcto Espacio:en_vz_dump: El espacio para las copias de seguridad de los servidores virtuales es suficiente por el momento. Procesos Activos: el número de procesos activos para que el servidor pueda gestionarlos es inferior a los límites establecidos PING: La respuesta al ping (icmp) está dentro de los umbrales de tiempo establecidos. Sería el único servicio, en este caso, que no sería un chequeo pasivo, a la espera de que el cliente NRPE le responda. Procesos zombies: el número de procesos zombies no supera el límite indicado Usuarios: el número de usuarios conectados simultáneamente al servidor no supera el mínimo para enviar notificaciones y cambiar su estado. Podemos comprobar, que por ser un servidor crítico, tiene enlace a Cacti para ampliar su información de forma gráfica más precisa y al complemento PNP4Nagios, que nos aportará más datos del comportamiento en todo el período del que se tiene información y que será visto con algo más de detalle más adelante. Servidor de aplicaciones Web En este caso, también se monitorizan aspectos de funcionamiento del propio servidor, pero además se tienen en cuentan otros aspectos fundamentales para el – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 104 funcionamiento de un servidor cuya principal función es servir un portal web, como vemos en la Figura 4.4: Error 500 www.midominio.es: Controlar que el servidor web no esté produciendo un error 500, lo cual indica que no se puede acceder a la página principal del portal. Inodos: el número de inodos, cuando es un sistema que gestiona muchos ficheros también se deberá tener en cuenta por si se debe ampliar este recurso del servidor. Puerto 5432 – Postgres: Comprobar que el puerto que debe aceptar peticiones a la base de datos, en este caso Postgres, está escuchando correctamente. Puerto 8080: Cualquier otro puerto, en este caso el 8080, puede comprobarse que está activo, por si a través de él se gestiona alguna administración. Servidor Windows A través del cliente NSClient++, según la Figura 4.5, obtendremos respuesta a los servicios que nos interesen más en este tipo de servidores Windows, alguno de – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 105 Figura 4.4. Monitorización Servidor de aplicaciones Web ellos, similares a los que poseen sistema operativo Linux, como en los anteriores casos, con la diferencia que aquí los sistemas de archivos serán identificados como unidades de red. El resto de aspectos como carga, uso de memoria o cualquier tipo de puerto, se realiza de la misma forma. Dispositivo tipo switch En este caso, en la Figura 4.6,el dato más importante, a parte de que esté encendido, será controlar que existe tráfico en los puertos del switch/router que podremos identificar con la etiqueta de la tarjeta de red o dispositivo del que deba proceder dicho intercambio de datos. En el caso del ejemplo, se comprueba que hay tráfico tanto de la Línea principal de la sede como la de respaldo, o bien, en la conexión con otro switch/router, así como, un enlace secundario. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 106 Figura 4.5. Monitorización Servidor Windows Sistema de copias de seguridad Para este tipo de servidores, una vez añadidas las alertas para los aspectos físicos, comprobaremos que se realizan las copias de las diferentes bases de datos y sistemas, así como el estado del espacio de diferentes NAS que tenga instalado y – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 107 Figura 4.6. Monitorización dispositivo tipo Switch Figura 4.7. Monitorización dispositivo tipo Backup PNP4Nagios: complemento que nos proporciona gráficas básicas del comportamiento de los objetos monitorizados. Consiste en añadir una llamada desde servidor/servicio deseado (en la siguiente Figura 4.16 se realiza mediante un icono en forma de estrella) al complemento que nos muestra la información que contiene hasta este momento y cómo se visualiza en la Figura 4.17: – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 114 Figura 4.16. Ejemplo llamada al complemento PNP4Nagios Figura 4.17 Ejemplo de gráficas del complemento PNP4Nagios – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 115 – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 116 Conclusiones Como ocurre muchas veces en la vida, la necesidad es la que nos obliga a buscar soluciones a los nuevos problemas que surgen a diario. La instalación de un tipo de herramientas como Nagios sobre la red informática de TASA, ha sido como encontrar la cuadratura del círculo. Actualmente, existe una red bastante compleja y se ha conseguido que sea estable, segura y fiable, por lo que el siguiente paso debía ser añadir un sistema que la monitorice y nos avise de aquello que consideramos un problema, error o simplemente, algo que no está funcionando correctamente. Tras haber realizado la implementación de la misma y llegado a un sistema de monitorización robusto, y sobre casi todos los recursos disponibles, hemos conseguido dedicar tiempo del departamento a otras funciones. Por otra parte, no menos importante, al ser alertados en cuanto se produce un problema, la capacidad de reacción es inmediata y, a la vez que se corrigen en menos tiempo, evitamos que se produzcan otros errores mayores. Desde luego, ha sido una de las aplicaciones que más ha colaborado al buen desarrollo del trabajo en el departamento informático de TASA. Por otra parte, se ha constatado que este aplicación está tan “viva” como la red que vigila, ya que casi a diario, aparecen nuevos elementos que deben ser monitorizados, o servicios que debemos añadir a los dispositivos ya existentes, así como, la incorporación de nuevos tipos de hardware y software, para los cuales en caso de no existir forma de vigilar su estado, se intentan desarrollar aplicaciones para ello. De hecho, el empleo de esta herramienta ha conseguido que tras surgir un problema en la red o después de que haya ocurrido alguno que era desconocido hasta ese momento, la solución para ser alertados lo antes posible, siempre pasa por implementar su control a través de Nagios y ser añadido a su configuración. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 117 Adicionalmente, hemos añadido complementos a Nagios y empleado varias aplicaciones complementarias para poder ampliar la información de lo que estaba ocurriendo cuando se produjo algún problema o para conocer el comportamiento de un elemento desde que se decidió vigilar, reuniendo así, toda la información posible para poder tomar decisiones de forma más rápida y segura. Para el futuro, entendemos que la herramienta debería incluir toda esta información sin que tengamos que depender de aplicaciones adicionales y sobre todo mejorar su información gráfica, la cual hemos comprobado que es bastante elemental. La principal conclusión a la que se llega tras la realización de este proyecto, es que durante el proceso de instalación de cualquier red informática, al mismo tiempo, se debería tomar la decisión sobre cuál de las herramientas de monitorización de redes, es la que mejor se adapta al tipo de red que se va a configurar, teniendo en cuenta con toda seguridad, que tanto el conjunto, como los elementos vigilados estarán en continua evolución y necesitará estar bien implementada para proporcionar seguridad a los responsable de la misma. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 118 Referencias bibliográficas Wikipedia: Imágenes y entradas sobre monitorización de redes y herramientas. Documento “3-Doc.Estado del Arte - Comparativo herramientas.pdf”: Archivo de referencia para el comparativo de herramientas de monitorización. http://www.nagiosexchange.org/: Página de la Comunidad Nagios http://www.nagios.org/: Página oficial de Nagios http://nagios.sourceforge.net/: Principal repositorio de Nagios http://www.cacti.net/: Página oficial de Cacti http://oss.oetiker.ch/mrtg/: Página oficial de MRTG http://es.wammu.eu/smsd/ : Página oficial de Gammu – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 119 Anexo 1. Plugins de Nagios check_alfresco check_dhcp check_file_exists check_http check_jabber check_mem.pl check_nntp check_nwstat check_radius check_snmp check_udp check_alfresco.jar check_dig check_flexlm check_icmp check_kvm check_mrtg check_nntps check_oracle check_real check_spop check_ups check_apt check_disk check_fping check_ide_smart check_ldap check_mrtgtraf check_nrpe check_overcr check_rpc check_ssh check_users check_breeze check_disk_smb check_ftp check_ifoperstatus check_ldaps check_mssql.php check_nt check_pgsql check_samba check_ssmtp check_virsh check_by_ssh check_dns check_game check_ifstatus check_load check_mysql check_ntp check_ping check_sensors check_swap check_virt check_clamd check_dummy check_hddtemp.sh check_imap check_log check_mysql_query check_ntp_peer check_pop check_simap check_tcp check_wave check_cluster check_file_age check_hpjd check_ircd check_mailq check_nagios check_ntp_time check_procs check_smtp check_time – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 120 Anexo 2. Ejemplos de plantillas Se muestran a continuación, detalles de definición de distintos tipos de plantillas. Una información más completa de todos los parámetros y sus posibles valores, pueden encontrarse en http://nagios.sourceforge.net/. Plantilla para contactos que deban recibir notificaciones mediante SMS, durante ciertas horas del día. #-------------------------------------------------------------- # Plantilla de contactos con SMS #-------------------------------------------------------------- define contact{ name sms ; The name of this contact template service_notification_period smshoras ; service notifications can be sent anytime host_notification_period smshoras ; host notifications can be sent anytime service_notification_options w,u,c,r,f,s ; send notifications for all service states, flapping events, and scheduled downtime events host_notification_options d,u,r,f,s ; send notifications for all host states, flapping events, and scheduled downtime events service_notification_commands notify-service-by-sms ; send service notifications via email host_notification_commands notify-host-by-sms ; send host notifications via email register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL CONTACT, JUST A TEMPLATE! } Plantilla para hosts genéricos, que deben estar continuamente monitorizados: se especifica que puede realizar envíos de alertas o ejecutar eventos, tiempos entre chequeos, etc. – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 121 #----------------------------------------------------------------------------- # Plantilla de la mayoría de los host, definidos en hosts.cfg #--------------------------------------------------------------------------- define host{ name generic-host ; Nombre de la Plantilla check_period 24x7 notifications_enabled 1 ; Notificaciones del host habilitadas (0,1) event_handler_enabled 1 ; Event Handler habilitado (0,1) flap_detection_enabled 1 ; Flap Detection habilitado (0,1) failure_prediction_enabled 1 ; Failure prediction Habilitado (0,1) process_perf_data 1 ; Processar datos de estado (0,1) retain_status_information 1 ; Mantener datos entre restarts (0,1) retain_nonstatus_information 1 ; Mantener non-status entre restarts notification_period 24x7 ; Enviar notificaciones todos los dias. check_interval 5 ; Actively check the host every 5 minutes retry_interval 1 ; Schedule host check retries at 1 minute intervals check_command check-host-alive ; Default command to check Linux hosts notification_interval 120 ; Resend notifications every 2 hours max_check_attempts 10 ; Máximo veces intentara probar un check notification_options d,u,r ; contact_groups nagiosadmin register 0 ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE! } #------------------------------------------------------------- # Plantilla dispositivos para control de presencia #------------------------------------------------------------- define host{ – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 122 name presencia ; The name of this host template use generic-host ; This template inherits other values from the generic-host template contact_groups nagiosadmin_presencia ; Notifications get sent to the admins by default } define host{ name generic-switch ; The name of this host template use generic-host ; Inherit default values from the generic-host template check_period 24x7 ; By default, switches are monitored round the clock check_interval 5 ; Switches are checked every 5 minutes retry_interval 1 ; Schedule host check retries at 1 minute intervals max_check_attempts 10 ; Check each switch 10 times (max) check_command check-host-alive ; Default command to check if routers are "alive" notification_period 24x7 ; Send notifications at any time notification_interval 60 ; Resend notifications every 60 minutes notification_options d,r ; Only send notifications for specific host states contact_groups nagiosadmin ; Notifications get sent to the admins by default register 0 ; DONT REGISTER THIS - ITS JUST A TEMPLATE } #------------------------------------------------------------- # Plantilla general de Servicios #------------------------------------------------------------- define service{ name generic-service ; The 'name' of this service template active_checks_enabled 1 ; Active service checks are enabled passive_checks_enabled 1 ; Passive service checks are enabled/accepted parallelize_check 1 ; Active service checks should be parallelized (disabling this can lead to major performance problems) obsess_over_service 1 ; We should obsess over this service (if necessary) – Sistema de monitorización de redes informáticas. Caso real 'Turismo Andaluz' – 123